¿Pero que cojones estás haciendo?
#61 un poco de todo lo que me pide la gente, cosas de backend en general.
ayer pues versionado de apis y como hacer sus clis con buena UX. lo primero un problema que me preguntaron y la cli un problema relacionado que me he encontrado muchísimo en diría todas las cli del mundo. en el post de ayer tienes la solución.
y como estos he ido tratando otros problemas típicos habituales de backend.
quería ensenar mas cosas pero no me dará tiempo. que test se deben hacer, que entornos y que workflows de CI y cuales no valen para nada. por ejemplo, los tests de controllers no valen para nada. como o como no generar stubs para acceptance y en que entornos es seguro (o como hacerlo seguro). me hubiese gustado ensenar SRE y profiling de producto, hoy en dia super necesario para todo backend... en su día hice una presentación y una clase por aquí de problemas que resolvimos con matemáticas y como la gente erronamente lo hace. etc.etc.
no se, hay muchísimos problemas que veo que los backend hacen mal, tanto en FAANGS como en startup Paco y me propuse resolverlos. ensenar a la gente es una buena manera de revisar las cosas, y hacerlo practico sirve para ver si te has dejado algo, y hacerlo publico sirve para que la gente pueda criticarlo.
la mayoría de estudiantes se piensan que backend es escribir endpoints con Spring, cuando backend es leer una factura de AWS, poner logs y metricas y alarmas e interpretarlas, hacer buen codigo, CI/CD, hacer profiling y leer trazas de syscalls en linux o leer un flamegraph etc.
11 días después
Ok, han pasado unas semanas y hemos crecido en número de desarrolladores en plantilla. Imaginemos que somos 10 empleados. ¿Compramos 10 *macs? Traigo una alternativa.
*Obviamente, vamos a trabajar con macs porque son lo mejor.
Necesitamos un entorno de desarrollo, a poder ser por programador, aunque realmente lo será por proyecto (según las dependencias). Requerimos que los entornos de desarrollo sean declarativos, funcionales y reproducibles y usables.
Tenemos dos alternativas:
- Comprar 1 entorno compartido
- Comprar 1 dispositivo por programador
Disponemos también de dos herramientas muy simples que a día de hoy son imprescindibles.
- nixos/foss: https://nixos.org https://flox.dev
- tailscale: https://tailscale.com
Vamos a ponernos que en lugar de comprar 10 macs, voy a alquilar 1 maquina en AWS, le voy a montar con tailscale 10 entornos de desarrollo y le compartiré los recursos. El primer cálculo de la vieja es que si un desarrollador requiere unos 16GiB de RAM, nuestra máquina necesita 160GiB de RAM. Voy a elegir una c5d.metal. No sé si sería la mejor, he elegido una cualquiera.
c5d.metal $5.328 96 192 GiB 4 x 900 NVMe SSD 25 Gigabit
Esta instancia esta en nuestra red de AWS, usamos nixos para settearla, tenemos roles de Github para automáticamente configurar todo el entorno de desarrollo. Si tenemos 10 repos, pues por ejemplo 10 carpetas con sus entornos y sus dependencias y 10 roles para cada programador. Os imagináis la idea verdad?
¿Cuánto es el coste por programador? $5.328 * 24 * 365 / 10 programadores = $4667.328
¿Caro no? Sí, y además este coste es anual.
¿Cuánto me saldría el MacBook Pro más o menos equivalente? $2.763 usd approx. (https://www.apple.com/es/shop/buy-mac/macbook-pro/14-pulgadas-negro-espacial-chip-m3-pro-de-apple-con-cpu-de-11-n%C3%BAcleos-y-gpu-de-14-n%C3%BAcleos-18-gb-memoria-512gb)
Vamos a suponer que vamos a ser 10 empleados estables, y tendremos los dispositivos 3 años.
- Costes renting AWS: $4667 * 10 * 3
- Costes comprar dispositivos: $2763 * 10
Ni hago los números. Mejor, hago preguntas.
¿Ahora viene lo interesante, realmente necesitamos el equivalente a 10 MacBook en computación, RAM y SSD? ¿Y necesitamos tener esta instancia corriendo 24 h al día x 365 días al año? Recordemos que nuestro entorno es declarativo, funcional y reproducible. ¿Siempre seremos 10 programadores al mismo tiempo? No, los requerimientos de máquina son dinámicos.
Hipotesis:
- Días laborables al año: 5 días x semana. 5 x 4 = 20 días por mes. 240 días
- Horas laborables por día: 8 horas x día. HAHAHAH. Pongamos que el equipo trabajara 4 horas reales x día.
- Horas requeridas: 4 horas x dia * 240 dias = 960 horas
- Coste total: 960 horas * $5.328 = $5114.88
Epaaaa, se me pone la sonrisilla del bixo, pero si es el coste “anual” de dos MacBook, y trabajan 10 personas! Y no hemos asumido que requiramos MENOS de todo ese cómputo... lo que supondría menos instancias.
Pues esto que veis, es un proyectito muy interesante. Usando un proveedor cloud, nixos y tailscale podemos reducir el coste en dispositivos de cualquier empresa un 50%. Este proyectito en lugar de asumir algunos de estos datos, trabajará con un pool dinámico y re-alocara recursos dinámicamente.
Ahora sí, los costes de 10 MacBook son $27630, tenemos un rango de beneficio y de alocacion de pool dinámico muuuy amplio.
¡Recordad que hablamos de costes anuales vs costes a X años (comprando hardware o leasing), pero yo he considerado el cloud, lo suyo sería tener hardware propio también! Pero para hacer el experimento, usaria el cloud primero y luego calcularia si es viable.
#63 Dispositivos como tal van a necesitar si son trabajadores que contratas y no autónomos. Ya es un gasto añadido.
Y como controlas que un trabajador que esta 4h reales trabajando no está 8 consumiendo una instancia activa? Lo expulsas tras X tiempo de inactividad? En cierto modo dependes de como usen los empleados la plataforma para tener mas o menos gasto. Como se traduce esto en la experiencia para el trabajador?
La idea esta curiosa, es similar a como lo tienen google y otras empresas.
#64eondev:Dispositivos como tal van a necesitar si son trabajadores que contratas y no autónomos
Pueden ser ipads o thin clients.
#64eondev:Y como controlas que un trabajador que esta 4h reales trabajando no está 8 consumiendo una instancia activa? Lo expulsas tras X tiempo de inactividad?
Es una aproximación, lo que hacen los servicios cloud con sus instancias es exactamente lo mismo. Tienen un pool y alocan los recursos dinámicamente.
El supuesto es que se requieren unas 4 horas de CPU/MEM, que no 4h de idle. Cuanto más escales el servicio, y tengas datos de uso reales de tu producto. Recordemos que esto es un plan para empresas, mejor resultados tendrás.
Quizás una empresa Paco española trabaja de 9h a 19h. O quizás es una empresa con remote que trabajan todos distribuidos. Como más distribuido, peor.
#64eondev:La idea esta curiosa, es similar a como lo tienen google y otras empresas.
Esto se hace con GPUs.
El motivo que no se hace con CPUs es por seguridad a gran escala, sobre todo. Estamos hablando hasta los 100-200 empleados, quizás.
Linux no es seguro, necesitaríamos algo BSD seguramente a largo.
#64eondev:Como se traduce esto en la experiencia para el trabajador?
Asumimos Github o similar que nos gestione tema de seguridad con roles, tokens, oauth. Como he demostrado en este hilo con varios ejemplos.
Cada trabajador necesita un entorno de trabajo, este puede ser compartido. Por ejemplo, el equipo de front-end, puede usar un entorno. Y cada programador mediante git y su usuario, trabajar en la rama que quiera. Con Nix, puedes tener el entorno por path, así que podrías tener el entorno por trabajador directamente.
Estos entornos pueden ser cacheados, junto a sus dependencias, son reproducibles. Mediante Tailscale si tuviésemos 2 entornos y 2 dispositivos (estos son dispositivos lógicos no físicos) en el sistema, podríamos conectarnos de un dispositivo a otro.
Por ejemplo, trabajador A tiene entorno A y trabajador B tiene entorno B, A se puede conectar a B y debuggar algo juntos.
Cuando se levanta una instancia de trabajador A, con nix instalaremos el entorno A, y esto en el día a día será muuuy rápido con las caches. https://medium.com/earlybyte/the-s3-nix-cache-manual-e320da6b1a9b
Para el trabajador pues podria usar VScode o similares: https://tailscale.com/kb/1265/vscode-extension Podriamos hacer nuestros plugins para todos los IDEs.
Además, recordad que esto solo es entorno de desarrollo, tendríamos CI/CD a parte con multi-entorno. Pero esto sería fuera de esta red de Tailscale.
#63desu:lo suyo sería tener hardware propio también!
Todo el rato, pensar que hablo de máquinas y unidades “LÓGICAS”. Es decir, cuando digo una máquina, no tiene por qué ser 1 pieza de hardware, puede ser una VM.
Cuando hablo de comprar hardware propio, lo suyo sería comprar un rack pepino y partirlo en VMs de distintos tamaños.
Clarificación.
Ah sí, también, los márgenes de AWS son un 30%.
Se te olvida sumar descuentos en AWS el coste final en una empresa grande es bastante menor, tienes reserved instances que te salen al 40-50% del precio y puedes llegar a descuentos del 70% si se usan muchas máquinas. En nuestra empresa y otras como DataDog tienen descuentos similares en la factura final.
#68 El objetivo era explicar de manera simple cómo un proveedor funciona y como ganan dinero.
AWS tiene márgenes de 30%.
Se tiene que volver al hierro. Y se tiene que volver al hierro como lo he explicado.
No hay que hacer otro proveedor cloud. Tiene que ser local. Ship 
Plug 
Run 
.
Ando haciendo pruebas con el stack. Un controlador de micro vms y orquestar. Cuando defines el scope y no quieres hacer un Borg monstruoso los pasos son claros.
La experiencia para el administrador debe ser instalar un server y configurar. Y sales con una VPN partida en VMs. Que dinámicamente se adapta al registro de usuarios. Un usuario da de alta un dispositivo y sube una configuración de su entorno de trabajo. Y a partir de ahí no hay que hacer nada.
Piensa ahora en una Universidad. Un servicio público como Hospitales. Necesitan máquinas para investigación y operar. Puedes tener redes públicas de computación accesibles para todo el mundo.
Espero que nadie me hackee la IP jeje.
