Ocena pomysłu - środowiska deweloperskie on-demand

Cześć,

Badam potrzebę i chciałbym zapytać Was, co myślicie o poniższym pomyśle:

Platforma ze środowiskami deweloperskimi on-demand:

• bazy (różne, mysql, cassandra np), vmki + możliwe zdalnych desktopów, narzędzi + kubernetes

W skrócie, taki mikro AWS dla deweloperów za +/- 20-30% ceny AWS. Coś podobnego robi https://www.okteto.com/

Teoretycznie miałoby to rozwiązać ten problem:

With the shift to microservices architecture, standing up production- and pre-production environments is more complex and expensive than ever. The old approach no longer works: the canonical pattern of a few testing environments, one staging environment, and one production environment creates significant bottlenecks. Without sufficient investment in test environments, developers must wait for a test environment to become available, and faulty pre-production code can take the test environment down for the entire organization. Even with the best agile practices in place, environment bottlenecks anchor software teams to waterfall-level productivity.

Z góry dziękuję za pomoc!

TO czy + czy - przy roznicy cenowej ma duze znaczenie. Za -30% + odpowiednie SLA dla wielu firm byloby to kuszace. W szegolnosci jakbym mogl np. postawic duzy klaster C* i mial pewnosc ze ktos zadba o aktualizacje, oncall itp. So firmy ktore robia takie rzecz, np Instaclustr albo Datastax i sie mocno cenia.

A czym to miałoby się różnic od: gitpod, codespace, AWS Cloud9, Koding ?

Osobiście, używam czasami gitpoda i sobie cenię.

Poza tym odpowiedzią na ten tekst po angielsku problemu jest też poniekąd https://www.telepresence.io/

Łączenie się do zdalnego serwera aby postawić na nim środowisko deweloperskie za każdym razem brzmi dla mnie na rozwiązanie wprost z lat osiemdziesiątych

Personalnie wolałbym zainwestować w jakieś rozwiązanie w stylu https://github.com/cachix/devenv, które przynajmniej próbuje zaadresować problem ("budowanie oprogramowania oraz stawianie środowiska jest złożone"), a nie jedynie zoffloadować w inne miejsce.

Patryk27 napisał(a):

Łączenie się do zdalnego serwera aby postawić na nim środowisko deweloperskie za każdym razem brzmi dla mnie na rozwiązanie wprost z lat osiemdziesiątych

Czemu? Ja w swoich kilku projektach odpalam

./dev-deploy uat

i leci deploy na maszynę testową, a za 30-60 sekund jest wrzucone. Szybsze niż push i deploy na test z workflowa.

Poza tym, zależy co masz na myśli mówiąc "za każdym razem"? Bo ogólnie dewelopuję cały feature na lokalu normalnie; wrzucam coś na maszyne testową tylko wtedy kiedy mam taką potrzebne, np chcesz sprawdzić klucze webhooków.

Dzięki za odpowiedź. Bardziej coś takiego jak https://www.civo.com/, przy czym to są klastry kubernetesa as a service, a ja bym bardziej to określił jak coś podobnego do heroku kiedyś.
Taki aws do developmentu za śmieszne pieniądze.
Płacisz 10$/mc i masz tam potrzebne VMki, bazy danych, desktopy jako opcję, nie bulisz za transfer itp.

i leci deploy na maszynę testową, a za 30-60 sekund jest wrzucone. Szybsze niż push i deploy na test z workflowa.

Może mamy odmienne definicje środowiska deweloperskiego - dla mnie oznacza ono cały zestaw narzędzi (w tym potencjalnie kontenerów i/lub maszyn wirtualnych), które są potrzebne w celu dewelopowania aplikacji, np. kompilator, linker oraz zewnętrzne zależności (biblioteki systemowe itd.).

Płacisz 10$/mc i masz tam potrzebne VMki, bazy danych, desktopy jako opcję, nie bulisz za transfer itp.

W erze 12-rdzeniowych laptopów i komputerów z 64 GB RAMu czy łączenie się do zewnętrznych usług w celu postawienia tam VMki ma jeszcze sens? Nie mówię koniecznie, że nie, oczywiście - ale tak z mojego podwórka prędzej wolałbym postawić coś na swoim laptopie niż na zewnątrz, ponieważ nie ma ku temu technicznych przeciwwskazań.

Tutaj opis efektu: On-demand test environments help parallelize the software testing process and reduce environment drift, helping software teams ship higher quality code faster. Ephemeral, up-to-date, production-like environments help engineers isolate their changes and diagnose issues quickly before they show up in production. These next-gen environments providers also have the opportunity to automate production deployments, diminishing toil for DevOps engineers as well.

Patryk27 napisał(a):

i leci deploy na maszynę testową, a za 30-60 sekund jest wrzucone. Szybsze niż push i deploy na test z workflowa.

Może mamy odmienne definicje środowiska deweloperskiego - dla mnie oznacza ono cały zestaw narzędzi (w tym potencjalnie kontenerów i/lub maszyn wirtualnych), które są potrzebne w celu dewelopowania aplikacji, np. kompilator, linker oraz zewnętrzne zależności (biblioteki systemowe itd.).

A, no widzisz.

• Lokalne środowisko developerskie - zgoda, kompilator, linker wszystko się zgadzamy (to nie o tym mówiłem)
• Zdalne środowisko developerskie - miałem na myśli aplikacje wdrożoną na server zdalny bardzo podobny do produkcyjnego, bez żadnych narzędzi developerskich (wrzucona jest skompilowana wersja), ale można ją zepsuć i nic się nie stanie. Bo tak się mówi: środowisko produkcyjne, środowisko testowe, etc. Ale w sumie faktycznie słowo "środowisko" nie pasuje. Powinienem powiedzieć "server developerski".

Miałem na myśli to drugie. Ale masz rację, lokalny komputer na którym kodzę też się przecież nazywa "środowisko developerskie".

Patryk27 napisał(a):

Łączenie się do zdalnego serwera aby postawić na nim środowisko deweloperskie za każdym razem brzmi dla mnie na rozwiązanie wprost z lat osiemdziesiątych

Teraz już rozumiem o co Ci chodziło.

Tak, dokładnie tak brzmi.

Chociaż pracowałem rok temu w firmie (ponad 10tys. pracowników) która odeszła od personalnych komputerów, na rzecz remote stationów właśnie.

Riddle napisał(a):

Chociaż pracowałem rok temu w firmie (ponad 10tys. pracowników) która odeszła od personalnych komputerów, na rzecz remote stationów właśnie.

No właśnie, zaczyna się o tym coraz więcej mówić, że świat zmierza w tym kierunku. Stąd pytanie o Wasze opinie i próba oceny na ile takie rozwiązanie to must-have, a na ile nice-to-have.
Mi bida wersja AWS pod development, gdzie nie tracisz czasu na konfigurację wszystkiego, wydaje się ciekawą opcją. Masz tam wszystko, od baz, bo VMki, desktopy, kubernetesa itp... Można testować, sharować itp Jednak "każda sroczka..." ;) Wiadomo jak jest, stąd fajnie usłyszeć konstruktywną krytykę, przed władowaniem się w temat.

wopper napisał(a):

Riddle napisał(a):

Chociaż pracowałem rok temu w firmie (ponad 10tys. pracowników) która odeszła od personalnych komputerów, na rzecz remote stationów właśnie.

No właśnie, zaczyna się o tym coraz więcej mówić, że świat zmierza w tym kierunku. Stąd pytanie o Wasze opinie i próba oceny na ile takie rozwiązanie to must-have, a na ile nice-to-have.
Mi bida wersja AWS pod development, gdzie nie tracisz czasu na konfigurację wszystkiego, wydaje się ciekawą opcją. Masz tam wszystko, od baz, bo VMki, desktopy, kubernetesa itp... Można testować, sharować itp Jednak "każda sroczka..." ;) Wiadomo jak jest, stąd fajnie usłyszeć konstruktywną krytykę, przed władowaniem się w temat.

No mi się na tym bardzo słabo pracowało. Lagi klawiszy i myszki rzędu 300-800ms. Nie do przyjęcia.

Patryk27 napisał(a):

W erze 12-rdzeniowych laptopów i komputerów z 64 GB RAMu czy łączenie się do zewnętrznych usług w celu postawienia tam VMki ma jeszcze sens? Nie mówię koniecznie, że nie, oczywiście - ale tak z mojego podwórka prędzej wolałbym postawić coś na swoim laptopie niż na zewnątrz, ponieważ nie ma ku temu technicznych przeciwwskazań.

Mi bardziej chodzi o to, o czym pisał @Riddle , czyli server developersk, dla ludzi, którzy developują do chmury.

Riddle napisał(a):

No mi się na tym bardzo słabo pracowało. Lagi klawiszy i myszki rzędu 300-800ms. Nie do przyjęcia.

Nie no - wiadomo, to musi działać. :)

wopper napisał(a):

With the shift to microservices architecture, standing up production- and pre-production environments is more complex and expensive than ever. The old approach no longer works: the canonical pattern of a few testing environments, one staging environment, and one production environment creates significant bottlenecks. Without sufficient investment in test environments, developers must wait for a test environment to become available, and faulty pre-production code can take the test environment down for the entire organization. Even with the best agile practices in place, environment bottlenecks anchor software teams to waterfall-level productivity.

Fajnie napisane, ale jak dla mnie, to wiele z tego nie wynika.
Co konkretnie jest źródłem problemów?

"gdzie nie tracisz czasu na konfigurację wszystkiego" hola hola, stop, nie rozumiem. Przecież wszystko trzeba skonfigurować i tak - czy lokalnie, czy twoja usługa chmurowa. Wspominasz o bazach danych - weźmy Postgres-a bo aktualnie go używamy. Jeśli potrzebujesz jakichś modułów albo dziwnych rozszerzeń, to i tak musisz to poustawiać w obu przypadkach. Jeśli wystarcza stockowa konfiguracja, to również w obu przypadkach nic nie trzeba robić. Mam wrażenie że próbujesz sprzedać coś co nie istnieje.

A odnośnie Kubernetesa to już w ogóle bzdura, bo tam to jest dopiero konfiguracji :) no chyba że odpalamy publiczne obrazy bez komunikacji pomiędzy i bez ingressów, ale to wtedy minikube start daje mi to samo za darmo.

Tak, zapytają czym się będzie różnić, potem powiedzą, że nie ma sensu, a za miesiąc zobaczysz produkt na półce he he he.

Takie coś mi dzisiaj w moim feedzie wyskoczyło :

https://github.com/coder/coder
https://coder.com/

czy przypadkiem nie jest to dokładnie to o czym ten tutejszy pomysł jest ?

Ja to mogę powiedzieć że bardzo dobry pomysł, ale i tak nie kupię bo nie mam wpływu na budżet w projekcie