javisantana.com · rss · rss resumen semanal

"Micro" es un pequeño blog (2 minutos de lectura por post), sin ruido, sin distracciones donde escribo las cosas que me gustaría leer. Recibe un correo cada fin de semana con las actualizaciones y "comentarios del director"

Cloud computing

Hace ya unos años se empezó a hablar de cloud computing.

Para los nativos digitales poder tener máquinas bajo demanda es lo lógico. Para empresas donde los desarrolladores tenían que decir 6 meses antes que máquinas iban a necesitar para poder pedirlas, instalarlas y demás era la panacea.

De hecho, una de las cosas que más te choca cuando empiezas a trabajar con el corporate como proveedor de software es que te piden que les digas el aprovisionamiento necesario para X usuarios. Que dicho de paso, no tienes ni idea porque tienes la falsa seguridad de que tu software escala añadiendo máquinas y bueno, porque saber medir y ajustar la carga requiere de un control absoluto de la mayoría del software que usas y/o tener experiencia con algo que te aplaste (yo aprendí por fuerza bruta gracias a Google y el WSJ)

Sin embargo la nube se vendió como un sitio maravilloso dónde tú no tenías que preocuparte de nada, tu software escalaba solo. Típico overselling que cualquier mid manager se podía tragar. Con lo fácil que hubiese sido dejarlo en “tu infrastructura bajo demanda, en menos de 1 minuto”. Hoy muchas empresas desarrollan como si tuvieran esa capacidad y están “limitadas” por un datacenter con poca capacidad de cambio. O por el dinero, porque levantar máquinas es fácil, pero luego nos encontramos con facturas de 20k/mes.

La realidad del asunto es que empresas como Amazon, Google pueden desarrollar software distribuido resiliente que puede correr en hardware barato que muere cada dos por tres. Y pueden desarrollarlo porque tienen gente muy buena en ese área, que sabe como hacer software distribuído e invierten años en hacer que funcione bien. Pero la mayoría de desarrolladores al uso nos quedamos en lo que nos da el framework (4 ó 5 niveles por encima de entender lo que significa una split de red), todos veníamos de tener hardware muy bueno (y caro).

La derivada de eso es que tu software sigue pensado para correr en cosas que no falle pero usando servicios AWS que si están pensados para correr en cloud. El paradigma de hacer software par a la nube se basa no en seguir un paradigma (que como digo, es muy complicado y caro) si no en usar unos servicios que nos proveen (a precio de oro). Así que es normal que todos los proveedores apuesten por microservicios, kubernetes y sistemas complejos donde necesitas apalancarte en su tecnología. Esto no es necesariamente malo, pero no todo el mundo lo necesita (y puede admitir esa complejidad).

La jodido de esto es que no hace mucho hablábamos de “el grid”, dónde el sistema operativo se encargaba de gestionar la complejidad por ti. De hecho la unión Europea se gastó una millonada en proyectos de investigación, subvenciones que lógicamente trincaron los de siempre. Puedes ver el proyecto xtreemos aquí.

Así que en vez de trabajar en software que sea capaz de paralelizar trabajamos en integraciones con servicios. Lo triste es que lo más parecido a un paradigma cloud son las famosas aws lambda/google run.

Necesitamos otro Torvalds y gente con un poco de cabeza que entienda los problemas que están por venir: Jonathan Blow - Preventing the Collapse of Civilization

· #

Data Lake, parte V: Autorización

Tienes todos los datos de tu empresa en un solo sitio. Nadie en su sano juicio permitiría acceder a todos los usuarios a todos los datos. Esto obviamente no aplica tanto a una pequeña empresa, aquí con dar acceso de solo lectura a una réplica de la base de datos de producción [1] para que la herramienta de BI de turno pueda coger datos es más que suficiente. Eso sí, no llames a esto “democratizar el acceso a datos”, el término sería “anarquizar el acceso a datos”

Porque hoy hay 30 personas en tu organización pero mañana hay 120 y luego 119… me sigues no? Esta es una razón para dejar que ciertas personas vean solo ciertos datos, pero hay otras, por ejemplo simplificar la vida de la gente.

De ahí que tengas que tener un control de acceso (autentificación). Esto es tan viejo cómo que la cueva Alibaba ya tenían un password

Pero ahora podemos hacer algo mejor que tener una sola puerta para la cueva, podemos tener sistemas de autorización robustos:

  • Tenemos sistemas de directorio donde tenemos registradas y agrupadas a las personas que forman parte de la organización
  • Deberíamos poder decir quién accede a qué con granularidad de fila/documento. Y esto a nivel de grupos y/o personas. Esto está resuelto por absolutamente todas las bases de datos decentes hace años. Y si el acceso es temporal, pues durante un tiempo. Y si el acceso tiene que ser a datos tokenizados, que así sea.
  • En la organización no solo hay personas, hay otra cosa llamada “software” que acceden al sistema, es decir, aplicaciones que usan estos datos (de hecho debería ser lo habitual). Estos bots/applicaciones deberían también estar registradas y gestionados. Hay cosas como oauth que podrían resultar muy útil aquí (mira como por ejemplo google da acceso a los diferentes datos de un usuario)

En este último punto es donde se suele pinchar si la empresa tiene cierto recorrido: es complicado entender que hay actores no humanos, que, de hecho, son los más importantes, porque como dice Vicki Boykis, los humanos estamos para dar significado a los datos, para procesarlos ya lo hacen mejor las máquinas.

[1] Evita como puedas dar acceso a la base de datos de producción, por mucha prisa que tengas.

· #

Integración continua

Time To Fix

Una metrica fundamental (*) que cualquier equipo de desarrollo/producto (bueno, en realidad toda la empresa debería estar involucrada aquí) debe medir y mejorar es el tiempo desde que un cliente tiene un problema hasta que ese mismo cliente deja de tenerlo.

Parece una metrica tonta, es facilísima de medir, basta con tener un tracker de issues e ir cambiando los estados a medida que la fases (reporte, evaluación, fix, deploy, test, close). Sí, esto es el peñazo universal, pero también lo era ponerte el cinturón de seguridad al montarte en el coche ahora no puedes avanzar un metro sin él puesto.

“deployear”

Una de esas fases es el deploy, es decir desde que tu código está en el control de versiones, hasta que llega a estar en producción.

Nadie ya discute que ese es un buen procedimiento, que debe estar automatizado y responder a cambios en el repositorio.

Vale, ahora imaginad que retrocedemos 20 años en la época en la que había un servidor FTP donde unos ficheros PHP era ejecutados por apache. O incluso unos scripts corriendo por CGI (las lambdas de hace unos años, para los milenials)

Imaginaos editar directamente esos ficheros en producción, es decir, cuando guardas en el editor la siguiente request ya usaría el nuevo código.

Nos hemos acostumbrado a cosas lentas

Obviamente hay muchas razones para no hacer esto, pero así se hacia hace años y es el en lo que tienes que pensar cuando tu deploy tarda 30 minutos: el baseline son unos milisegundos, así que todo lo lejos que estés de milisegundos lo estás haciendo peor que hace 25 años.

Digo obviamente pero yo no tengo tan claro que las herramientas actuales de desarrolladores no sean “caballos más rápidos” y no coches como diría Ford. Lo mejor que he visto últimamente en esta línea es esto y glitch, que está empezando de juguete pero “ojo lluvia” que viene de gente que sabe como hacer producto web. Pero este tema da para otro post.

Nos hemos acostumbrado a que las cosas vayan lentas a cambio de unas promesas que, en muchos casos, no son ni media verdad.

(*) Si tienes un equipo de desarrollo mediano (+10) la métrica TTF (time to fix) es un driver buenísimo para mejorar la calidad del desarrollo. Y además si eres CTO te sirve como métrica para poner en el excel para los inversores (que siempre es un peñazo encontrar buenas métricas)

· #

pico8

Había visto ya hace un tiempo gente publicando imágenes con el hashtag #pico8 y me habían llamado la atención pero nunca me he parado a ver de qué iba y no sé si es nostalgia pero estoy enganchado.

Básicamente es una consola virtual, con sus cartuchos virtuales con un par de peculiaridades: el developer es first class citizen y las restricciones son muchas, por ejemplo, tienes una paleta de fija de 16 colores, el tamaño de la pantalla es 128x128px (hay favicons más grandes) y un máximo de tamaño de juego de 64kb. Solo hay que echar un ojo al cheatsheet

Y esto hace que como producto sea espectacular. Tiene todo lo que necesitas para hacer un juego (lógica, sprites, mapas, efectos de sonido y música (*)) en el mismo sitio, te permite hacer virguerías, pero te las restricciones te obligan a hacer las cosas super sencillas.

Nada de complicaciones, con esos recursos tienes todo lo necesario, eso sí, crear, modificar y usar esos recursos en el juego es muy muy fácil, así que las limitaciones se convierten en una ventaja.

Cómo plus tiene un halo retro y una filosofía del software noventero preinternet que hace echar de menos la época de cuando el software lo hacía gente en otra liga.

(*) Si te interesa la generación de audio procedural escribí un artículo hace unos 14 años sobre como generar audio en demos de 4kb.

· #

Joinable API

TLDR: nowadays any software service depends on others. The problem is your data ends up being distributed and there is no easy way to join those different sources easily. I’m proposing a “joinable API” to fix that problem.

Data lock-in

We have been talking about the vendor lock-in for years, where once you start using a provider it’s nearly impossible to move to a different one. I think the software world is like that no matter the software you use: once your software is running on production changing it is a really expensive and painful task.

Before the explosion of SaaS providers we had data exporting tools so you could more or less get your data in a standard format and import to another system. Today that’s not totally true: try to get all “your data” from your google analytics account. Don’t worry, those providers have tools that can access your data easily.

Hundred of services

10 years ago was easy to see a monolithic services running on just one big machine with everything needed in there (user management, accounting, the service itself) today you start a company and the one week later your software is talking to several services through HTTP APIs.

That’s good, you spend your time in the thing you provide more value instead of doing billing code.

Give me some stats

Eventually, someone will ask a question like “hey, how many users do we have in our XXXX tier, have signed up 3 times during the last month and also have ….”

So you either 1) use a platform that collects everything or 2) a one that fetches data from all those services and put data in a place you can query. in any case, querying data from a third party services is a pain. Here is the point where a lot of scrapping and “CSV file transfer” horror stories start.

Joinable API

Most of those operations are what we call joins. It’s easy to do when all the data is in the same place but hard to do in a distributed system.

So how do we keep those services and at the same time the possibility of using our data? why don’t we request to our service providers to have a Joinable API apart of full, easy to use and documented data dumps and their regular service API (more on this in this excellent talk)

Tech solution

Let’s imagine you have a regular OLTP database like Postgres, it’d be nice to be able to do:

SELECT * FROM MyTable 
JOIN Service('billingservice.com', 'transactions')
ON ... 
WHERE date = yesterday() ...

fetching remote data is already supported by Postgres using FDW (and all databases have a way to fetch remote data) but the problem is getting the data from the service.

The service would need to provide:

  • An API endpoint that exposes resources. It does not need to be HTTP but it’d work.
  • Each resource should be able to return a list of columns ordered by a column (so merge joins, the common ones in these operations are faster) with some filters (so databases can push down them)
  • Most likely the data format should be columnar so it takes less time over the network. An example dataset with 1M rows, 12 columns takes about 10mb with the data well prepared (compressed binary columnar data format). 1M rows are enough to cover most of the common use cases.
  • Ideally, some aggregations should be possible.
  • It must be really fast. That’s key but “batch” APIs traditionally have been slow.

This is what most of the distributed databases do, it’s not rocket science, a common well-tested pattern that every single service should expose so you don’t have data lock-in.

· #

Data lake parte IV, los cambios

El modelo de datos cambia sí o sí, básicamente porque modelan la vida real y la vida real cambia. Mucho.

Queremos que las cosas no cambien

Todas las bases de datos series tienen mecanismos para cambiar la forma de los datos. Es muy simple añadir una columna, cambiar el tipo o el nombre. Hay algunas incluso que el cambio es la constante como las orientadas a documento.

Dado que van a cambiar queremos:

  • Mantener todas las versiones de los datos
  • Tener registro de todos esos cambios
  • Poder consultar esos datos como si no hubiese cambios

Esto es más o menos trivial a nivel de gestión, lo complicado es saber cuando los datos han cambiado. Parece fácil, pero no lo es, a menudo los desarrolladores cambiamos el modelo de datos, el interfaz del API sin tener en cuenta todos los sistemas afectados.

Los tipos de cambios

Hay dos cambios fundamentales (bueno, seguramente más, pero estos son los peores) que se pueden producir en los datos:

  • Un cambio del esquema, es decir, hay una nueva columna o una vieja desaparece. Una columna ahora puede tener valores vacíos.
  • No hay cambios de esquema pero la semántica del dato es diferente. Un atributo pasa de millas a kilómetros.

En ambos casos debe haber una diferencia clara.

El interfaz común

La clave del asunto es no afectar a los sistemas que dependen de estos datos (si es posible). Si por ejemplo, se añade una nueva columna o atributo, es fácil hacer que los sistemas que beben información sean compatibles.

Si pasamos de millas a kilómetros es fácil que la mayoría de sistemas se vuelan locos. Tenemos dos opciones, o cambiar todos los sistemas que dependen de mis datos o expongo mis datos a través de un API en el que pueda multiplicar por 0.62 los datos en millas y por 1.0 los de kilómetros.

· #

Además de poder importar datos de forma sencilla hay otro tema fundamental que es saber qué datos has importado.

No me refiero solo a saber “el día 25 importamos estos datos” si no a saber de qué van esos datos:

  • Qué: datos de ventas
  • Cúando: creado el 7 de septiembre del 2018
  • Cómo: carga masiva de vaya usted a saber
  • Fuente: Oracle
  • Nombre Campos: A, B, C, D
  • Descriptión técnica de los campos: …
  • Descriptión de negocio de los campos: …
  • Relaciones de los campos con otras fuentes de datos: …
  • Historial de cargas

Obviamente son todos los que están pero no están todos los que son. De hecho hay un tema peliagudo que es el control de los cambios, pero eso lo vamos a dejar para la parte IV.

Pero esto no es todo. Aunque tengamos catalogados con absoluta perfección no solo tenemos los datos que entran, si no los que salen.

No tiene sentido tener un data lake sin poder explorar esos datos. Y lo habitual no es consultar los datos de entrada si no más bien datos derivados que muy posiblemente vengan de un JOIN (JOIN de SQL para los que vengan de usar Mongo) con otras 3 ó 4 fuentes de datos (alguna posiblemente externa). De hecho es casi más importante este catálogo como el de los datos de entrada. Pero de eso hablaré en la parte VII.

· #

Data Lake, parte II: las fuentes

Nadie crea una empresa con base tecnológica (*) y dice “empecemos pensando en el data lake”. Bueno, salvo que tu empresa sea de data lakes.

Si fuese así lo primero que crearísmos sería un equipo de data services que nos diera servicio para que los desarrolladores (y otras partes de la empresa, claro) pudieran almacenar los datos ahí.

Te imaginas tener un servicio donde un comercial conecte salesforce, una ingeniera cree “as a service” una base de datos para el core de la aplicación que sustenta el negocio y que todo estuviera en el mismo sitio y se puediera relacionar.

No hay que imaginarse mucho, AWS y Google llevan metiendo, poco a poco, todo su arsenal para que tus datos vivan allí y los consumas con sus, relativamente caros, servicios. De qué si no iba Amazon a darte S3 a un precio “tirado”?

Volvamos a la realidad.

El negocio crece, los datos crecen, el equipo crece, escalar tecnología es muy complicado, así que divides los equipos y eso hace que haya una o varias fuentes más de datos.

Llega nuestro amigo el data lake y dice: chavalada, sabéis esos datos que tenéis? pues me los tenéis que pasar o dejar recoger.

Esto en una empresa “nativa digital” es complicado, imagina en un corporate donde hay cientos de fuentes de datos, de departamentos diferentes. “a mi Oracle tú no entras que me lo tiras”, “estos datos son confindeciales”, “si borro un registro por imperativo legal (GPRD), como lo borras tú, amigo Data Lake”

Y aquí radica el principal y mayor problema de un data lake a nivel de organización. Así que toca hacer cosas como estas :

  1. Dejar de llamar al data lake “Data Lake” y empezar a llamarlo “servicios de datos”
  2. Hacer fácil que los equipos metan sus datos
  3. Hacer que los equipos sientan los datos como suyos aún dentro de un sitio común
  4. Hacer que los nuevos equipos/proyectos nazcan con los datos ya dentro del data lake

(*) La base de todas las empresas es la gente que pasa por ellas, la tecnología facilita.

· #

Data Lake parte I, Introducción

Yo no tengo ni idea de lo que es un data lake pero la definición se me parece a algo así: tira aquí todos los datos y ya veremos.

Pinta bien, si algún día necesitas no sé qué dato para hacer machine learning, ahí está, lo coges y lo usas.

Ahora, me pregunto: si es complicado mantener tus datos de producción, cómo demonios se mantiene mínimamente organizado, y por tanto usable, toda la cantidad de datos que genera una empresa.

Los datos son como el cuerpo humano: las partes que no ejercitas son grasa y esta pasa factura a largo (y a corto) y necesitas ejercitarlo para que funcione bien

Pero imaginemos que el data lake es perfecto:

  • II. Es capaz de recoger datos de todas las fuentes.
  • III. Tiene un catálogo de todos los datos con datos técnicos y de negocio
  • IV. Trazabilidad de cambios
  • V. Acceso segmentado por usuario
  • VI. Auditoría de lo que ha pasado
  • VII. Posibilidad de tener datos derivados (aplicando todo los anteriores)
  • VIII. Capaz de alimentar sistemas de producción (ML, bases de datos transacionales, excels…)

Me cuesta ver como alguien que no está acostumbrado a los datos pueda abrir Tableu, engancharlo ahí y sacar “insights”. A un desarrollador, en teoría más cerca de los datos, le cuesta trabajar solo con los datos de producción…

Me pregunto, no tiene sentido que la exposición de los datos sea también lo que llamamos “producto”?

· #

micro

Twitter es una maravilla, te permite hablar con gente y todo ese rollo que nos hace humanos. Pero:

Lo que escribes se va, aunque no tenga fecha de caducidad.

Lo que escribes es de twitter, cosa bastante justa porque ellos ponen la pasta.

Así que qué mejor que un repositorio donde almacenar esas cosas que, a veces, no entran en 200 y pico caracteres y que quiero que permanezcan.

Menos ruido, más contenido.

Esto es micro.

· #