Am citit articolul. M-a inspirat sa vad cat de complicate pot deveni lucrurile incat nici complexitatea Kubernetes-ului sa nu poata tine pasul.
In articol spun despre cum au avut ft multe dificultati, in principal din cauza ca Kuberntetes e designed pentru application workloads, pe cand cei de la Gitpod aveau nevoie de system workloads, adica cloud development environments.
S-au lovit de toate limitarile posibile: network, security, storage, resource sharing/scheduling/allocation.
Ce-au facut intr-un final, au dezvoltat o alternative la Kubernetes, numita Gitpod Flex, care adreseaza toate limitarile si problemele. E proiectat special pentru system workloads.
Desi vad ca nu e open-source acest produs. Nu-l gasesc pe GitHub.
Am avut in plan sa folosesc Tilt, devspace sau skaffold pentru local/cloud development. (inca am pe proiecte noi - nu e fezabil sa rulezi totul local dupa ce proiectul a crescut, iar cu proxy pe un singur env esti vulnerabil)
Faptul ca k8s e complex e putin spus, in special cand ai un proiect pe care backend-ul e de exemplu pe java si imaginile de baza sunt pe x64, dar tu lucrezi de pe mac cu ARM. Exista mai multe metode de a face deploy, helm charts/operator si chiar scripturi. Setarile la env difera de la cloud la cloud.
Pe backend cu microservicii trebuie sa gandesti totul in cap cu k8s, daca migrezi de la arhitectura netflix sau similar trebuie sa ai grija sa ai preemption pe servicii altfel cu k8s se vor reporni de cateva ori pana se aliniaza planetele. Asta e important local, fiindca stai 30 de minute sa iti porneasca tot dev env-ul cu k8s sau risti sa ramai fara memorie inainte ca serviciile de baza sa porneasca si sa orchestreze celalalte servicii.
Backend, front-end, pipeline-ul trebuie sa fie aliniate pe k8s, nu docker compose sau scripturi random.
Cu microVM-uri tot nu cred ca totul e roz, e roz pentru proiecte simple.
Am testat gitpod pentru interviuri, functioneaza destul de frumos.
In general orice proiect mai mare ar trebui sa ia in considerare un CDE, cu sau fara IDE. Majoritatea lucram cu laptop-uri care sunt limitate, in companii mai mari ai mult spyware/configuratii AD aiurea…
Chiar si daca ai contractori nu e o idee buna sa ii lasi sa lucreze doar de pe calculatorul personal fiindca nu stii ce fac pe langa proiectul tau.
Stiu ca la banci/asigurari/SAP se lucreaza direct cu masini virtuale, un CDE e doar o masina virtuala care nu ruleaza pe calculatorul tau si poate fi mult mai bine optimizat, scalat daca e doar pe linux. Pe calculatorul tau ramane doar IDE-ul care se conecteaza la VM si browserul pe care testezi.
Desigur ca nu cred ca se aplica pe mobile/game dev/aplicatii native.
Ar fi pont daca tot e remote development environment sa ai acces direct la VPC network, sa ai access la serviciile native de AWS (lambda, SQS …). Numai ca atunci ar fi deja un hussle operational la infrastructura de AWS.
Nu-ti poti permite sa faci cate un env pentru fiecare dev. Pana la urma acele remote environments ma gandesc ca vor avea tot niste database-uri pe localhost, un redis/rabbitmq pe localhost (adica in network-ul privat al developer-ului).
Sau poate sa foloseasca shared test environments (between teams/developers).
Daca vorbim de Kubernetes: faci cate un cluster pentru fiecare developer? Faci cate un namespace pentru fiecare developer? …
Practic, as spune ca mult se rezuma la infrastructura dedicata. Cat de multa iti permiti sa cheltui, sa operezi…
Din pacate fiecare proiect mai mare ar trebui sa aiba un env dedicat per developer, in special daca sunt multi altfel calcati frecvent unii pe coada altuia. Daca ai env-ul in AWS EKS poti sa ai acces la tot ce tine de AWS, plus AWS are session manager-ul care e destul de elegant, poti sa faci un token vending machine. Nu mai ai nevoie de bastion host.
Problema da, e ca devine foarte foarte scump si trebuie tinuta contabilitatea la cat costa.
Solutia de mijloc e sa rulezi anumite servicii in cloud si anumite servicii local. (e posibil cu k8s)
Dacă mergi un pic mai departe cu ideea: fiecare developer ar trebui să aibă posibilitatea să-și “deployeze” servicii de suport în cloud. De exemplu într-un proiect bazat pe microservicii, nu vreau să rulez toate microserviciile local. Rulez doar microserviciul meu dar se conectează la restul microserviciilor în cloud într-un mediu care este controlat și customizat tot de mine. Și totul efemer: când nu mai am nevoie, închid tot!
Ideea asta de cloud as support îmi place cel mai mult.
Exista mai multe metode de a face deploy, helm charts/operator si chiar scripturi. Setarile la env difera de la cloud la cloud.