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.
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.
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.
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.
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.
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)
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:
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.
El modelo de datos cambia sí o sí, básicamente porque modelan la vida real y la vida real cambia. Mucho.
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:
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.
Hay dos cambios fundamentales (bueno, seguramente más, pero estos son los peores) que se pueden producir en los datos:
En ambos casos debe haber una diferencia clara.
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:
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.
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 :
(*) La base de todas las empresas es la gente que pasa por ellas, la tecnología facilita.