Kodowanie na laptopie jest passe

Spędziłem dekadę, kierując zespołami zajmującymi się narzędziami programistycznymi. W tym czasie obserwowałem rozkwit i upadek Vagranta oraz początki Dockera wraz z mnóstwem innych narzędzi do kompilacji. Pamiętam czasy, gdy większość deweloperów miała pod biurkiem dwa komputery stacjonarne, a ja pomagałem w masowej migracji na Macbooki.

Pomagałem również rozwijać wewnętrzne platformy do samoobsługowego przetwarzania danych w AWS. Wszystkie te narzędzia miały na celu zbliżenie środowisk produkcyjnych do deweloperskich oraz zapewnienie łatwej konfiguracji i skalowalności środowiska lokalnego. Jednak nic z tego nie trafiło w sedno.

Od czasu gdy zacząłem pracę w Palantir, rozmawiałem z wieloma różnymi menedżerami o tzw. developer experience. Okazuje się, że istnieją pewne wspólne tematy:

• Wielu deweloperów boryka się ze słabą wydajnością swoich laptopów. Może to być spowodowane dowolną kombinacją źle dostrojonych narzędzi bezpieczeństwa, ciężkich procesów lokalnych, a często sam Chrome jest już dużym problemem.
• Większość firm zmaga się z kwestią Mac vs. Linux vs. Windows. W większości przypadków zespół IT utknął na etapie dostarczania wszystkich trzech rozwiązań. Zawsze znajdzie się jakieś narzędzie lub biblioteka, która działa na tyle inaczej, że może powodować problemy. Potem pojawia się coś takiego jak chip M1 Maca i rozpętuje się piekło.
• Frontend deweloperzy mają trudności ze współpracą z projektantami UX. Zwłaszcza w obecnym zdalnym świecie większość firm nie dysponuje dobrymi rozwiązaniami pomagającymi projektantom i programistom współpracować. Wiele firm nadal polega na zrzutach ekranu lub krótkich filmach wideo, prezentując nowe komponenty interfejsu użytkownika - coś strasznego, swoją drogą.
• Laptopy o wysokiej wydajności są drogie. Jeśli masz aplikację wymagającą dużej mocy obliczeniowej, prawdopodobnie wydajesz 4 tys. dolarów na programistę i kolejne 4 tys. dolarów za każdym razem, gdy się upije i zostawi laptopa w barze.

Ale szczerze mówiąc, nic z tego nie ma znaczenia w porównaniu z tym punktem:

• Większość inżynierów nie jest zachwycona swoim lokalnym środowiskiem. Bądź szczery/a: czy korzystanie z laptopa sprawia ci radość? Czy może laptop przeszkadza ci w pracy? A może Ci w niej pomaga?

Jeśli bez wątpienia uwielbiasz swojego laptopa i nigdy nie musiałeś zamykać większości swoich aplikacji, aby kolejne cholerne spotkanie na Teamsach się nie zacinało, to ten artykuł nie jest dla Ciebie. Uciekaj stąd.

Rozwój zdalny polega na tym, że maszyna zdalna wykonuje wszystkie procesy kompilacji i testowania, a laptop służy jedynie jako przeglądarka lub cienki klient.

Chcesz pominąć czytanie reszty tego artykułu? Możesz po prostu przejść bezpośrednio do tego repozytorium na GitHubie i wypróbować Coder OSS w 20 minut. Jeśli chcesz dowiedzieć się więcej o tym, dlaczego zdalne programowanie jest najlepszym środowiskiem programistycznym, czytaj dalej.

Dlaczego rozwój zdalny jest lepszy od rozwoju lokalnego?

Rozwój zdalny znacznie poprawia produktywność deweloperów

Podstawowym argumentem przemawiającym za zdalnym środowiskiem jest to, że przenosząc nakład pracy programistycznej na maszynę zdalną, można przenieść, skonfigurować i skalować maszynę zdalną znacznie szybciej niż przez kupowanie nowych laptopów dla programistów. Jeśli zdalna maszyna jest zoptymalizowana pod kątem danego przypadku użycia, może wykonać następujące czynności.

• Poprawa szybkości kompilacji i testowania. Bazowa maszyna wirtualna może być skalowana i optymalizowana w celu dopasowania do potrzeb każdego indywidualnego projektu. W naszych eksperymentach udało nam się zmniejszyć szybkość kompilacji z 9 minut do 2.
• Redukcja opóźnień. Umieszczając zdalne środowisko w odpowiednim regionie, można znacznie zmniejszyć odległość do infrastruktury lub interfejsów API w chmurze. Dla australijskiego dewelopera pracującego na wschodnioamerykańskiej infrastrukturze usprawniło to kilka procesów 10-krotnie.
• Eliminacja czasochłonnych etapów konfiguracji. Każde repozytorium ma kroki konfiguracji, które można zautomatyzować, co jest znacznie łatwiejsze, gdy kontrolujesz obszar roboczy. Jest to szczególnie prawdziwe w dużych organizacjach ze starszymi repozytoriami. Zautomatyzuj instalację raz, a oszczędzisz wszystkim czasu.
• Wiele środowisk. Podczas wykonywania dużej aktualizacji biblioteki można równolegle uruchomić drugi obszar roboczy dla tego przypadku użycia. Dzięki temu modyfikacje środowiska są ograniczone, co umożliwia dalsze pisanie kodu w oparciu o oryginalną bazę kodu.

Po raz pierwszy zetknąłem się z tym modelem u inżyniera, który używał code-server (zauważ ilość gwiazdek!) na zdalnej maszynie wirtualnej. Jego głównym problemem było to, że nie był w stanie sprawdzić i zbudować dużej bazy kodu, ponieważ jego laptop był tak obciążony narzędziami bezpieczeństwa, że jego IDE się wykrzaczało.

Nie mieściło mi się to w głowie, ale zdałem sobie sprawę, że ten model nie będzie skalowany. Maszyny wirtualne mogą być bardzo drogie, a uruchamianie jednego lub więcej środowisk na dewelopera byłoby nierozsądne. Deweloperzy potrzebują swojego środowiska działającego tylko w godzinach pracy, a ten rodzaj użytkowania jest idealny dla Kubernetes.

Kubernetes i zdalne środowiska programistyczne

Wdrożenie środowiska rozwoju zdalnego jako platformy Kubernetes rozwiązało moje problemy związane z kosztami i konfiguracją. Mogłem kontrolować środowisko wykonawcze, obrazy bazowe i praktyki bezpieczeństwa, a także mogłem zaoszczędzić pieniądze poprzez skalowanie wertykalne i horyzontalne mocy obliczeniowej, gdy programiści rozpoczynali i kończyli swój dzień pracy.

Jak pokazano powyżej, idea polega na tym, że każdy deweloper ma swój własny trwały wolumen, ale jego bazowy kontener może być efemeryczny. Ponieważ koszty pamięci masowej stanowią niewielki ułamek całkowitych kosztów obliczeniowych, umożliwia to programistom uruchamianie naprawdę potężnych kontenerów w ciągu dnia pracy, podczas gdy ich firma wieczorami i w weekendy wydaje zaledwie grosze.

Czy rzeczywiście uważam, że rozwój lokalny jest na wymarciu?

Ok, tak naprawdę nie wierzę, że umrze, ale nie dlatego, że mam bardzo przekonujący argument. Największe organizacje takie jak Google i Facebook, od lat korzystają ze zdalnego modelu developmentu. Natomiast trzeba było trochę czasu by narzędzia open source były łatwe i przyjemne w używaniu.

Najbardziej rozsądnym kontrargumentem jest to, że zdalny rozwój nie jest idealny dla programistów, którzy pracują w obszarach ze słabym dostępem do Internetu. Chociaż jest to prawdą dzisiaj, to dzięki rozwiązaniom takimi jak Starlink i ASTS, wierzę, że tylko kilka lat dzieli nas od tego, by globalnie dostępny Internet stał się rzeczywistością dla wszystkich.

Drugim najbardziej rozsądnym kontrargumentem jest doświadczenie związane z rozwojem zdalnym pakietu IDE JetBrains. JetBrains wydał aplikację Gateway w 2021 roku, aby rozwiązać te kwestie. Niestety, aplikacja ta była początkowo trudna i nie polecałbym jej pełnoetatowym użytkownikom IntelliJ lub Webstorm. Jednak w ciągu ostatniego roku poczyniła znaczne postępy i spodziewam się, że w ciągu 1-2 lat użytkownicy nie będą czuć dużej różnicy w stosunku do rozwoju na lokalnym sprzęcie.

Szczerze mówiąc, głównym powodem wahania jest brak przekonania, że IDE oparte na przeglądarce byłoby akceptowalne dla pełnoetatowego programisty. Musi lagować, być trudne w użyciu, zawodne lub jeszcze coś nieprzyjemnego, prawda?

Tutaj błyszczy CoderOSS. Jest to darmowy sposób na przekonanie się, jak może wyglądać rozwój zdalny dla programistów. Najlepszą metodą jest samodzielne wypróbowanie.

Uruchom ekosystem rozwoju zdalnego w mniej niż 20 minut

Stworzyłem łatwe w użyciu repozytorium jako ścieżkę demonstracyjną, aby pokazać, jak wygląda zdalny Visual Studio Code na Kubernetes. Zdecydowałem się skorzystać z hostowanej przez Google usługi Kubernetes, ponieważ oferuje ona kredyt w wysokości 300 USD, a GKE Autopilot jest bardzo prosty w użyciu.

Instrukcja instalacji Coder

• Utwórz konto Google Cloud, projekt i konto usługi w tym projekcie za pomocą uprawnień edytora.
• Zrób kopię mojego repozytorium i skonfiguruj je z spacelift.io lub czymś podobnym
• Zestaw GOOGLE_CREDENTIALS i TF_VAR_project z id projektu powyżej
• Uruchom i zastosuj Terraform.

Cała konfiguracja powinna zająć mniej niż 10 minut, a jeśli jesteś nowym użytkownikiem Google Cloud, to może to potrwać nieco dłużej.

Instrukcja konfiguracji Coder

• Przejdź do adresu IP load balancera (Google Cloud / Kubernetes Engine / Services & Ingress).
• Utwórz początkową nazwę użytkownika i hasło.
• Przejdź do Templates / Kubernetes / Create Workspace i nadaj mu nazwę.
• W ciągu 3 minut powinieneś zobaczyć to:

• Kliknięcie “code-server” powinno otworzyć nową kartę przeglądarki z VSCode uruchomionym na zdalnym systemie.

Nie wiem jak ty, ale gdy pierwszy raz to zobaczyłem, to nie mieściło mi się to w głowie. Byłem przyzwyczajony do świata Windows RDP lub VNC, a pomysł używania przeglądarki jako mojego głównego IDE wydawał się jakąś tanią sztuczką. Jednak po zobaczeniu tego w akcji zostałem kupiony.

Jakie rodzaje problemów najlepiej rozwiązuje rozwój zdalny?

Od lat kieruję zespołem deweloperów i jestem oddanym zwolennikiem DevOps (a przynajmniej DevOps opisanego przez Phoenix Project). Mogę powiedzieć, że choć optymalizacja przestrzeni roboczej deweloperów w firmie jest ważna, to może nie być tutaj najważniejszym problemem. Jeśli którykolwiek z poniższych problemów jest jednym z najważniejszych, warto rozważyć zdalny rozwój.

Problemy, które dobrze nadają się do rozwoju zdalnego

• Długie czasy kompilacji, wykonywania lub testowania (>5 minut) są zwykle ograniczone przez pewną kombinację mocy obliczeniowej, pamięci, dysku, sieci, opóźnień, a nawet systemu operacyjnego. Wszystkie te elementy można dostosować za pomocą modelu zdalnego rozwoju i można to zrobić indywidualnie dla każdego przypadku.
• Łatanie starego kodu może być czasochłonne, jeśli inżynier musi skonfigurować swoją lokalną stację roboczą do pracy z historycznymi wydaniami, starszym kodem lub po prostu rzadko dotykanymi bazami kodu. Po umieszczeniu środowiska w kontenerze, konfiguracja nie jest już ręczna i jest ograniczona jedynie czasem startu kontenera. Ponadto narzędzia, takie jak Coder, obsługują uruchamianie wielu środowisk na dewelopera, umożliwiając im uruchamianie dedykowanych środowisk dla poprawek bez zakłócania ich bieżącej pracy.
• Zabezpieczenie kodu źródłowego (tj. air gapping) jest konieczne, gdy mamy do czynienia z przepisami (tj. ITAR), systemami finansowymi lub systemami o krytycznym znaczeniu dla bezpieczeństwa. Wiele z tych organizacji dąży do pełnej izolacji, aby zapobiec wyciekom kodu źródłowego. O wiele trudniej jest utrzymać w izolacji laptopy deweloperskie niż kontener w centrum danych.

Rodzaje rozwoju, które dobrze nadają się do rozwoju zdalnego:

• Rozwój frontendu może odnotować duży wzrost produktywności rozwoju ze względu na zwiększoną pojemność obliczeniową/pamięci, a VSCode (najpopularniejsze IDE do rozwoju front-endu) działa bardzo dobrze ze zdalnym rozwojem ze względu na coder/code-server i jego zdolności do robienia backendu po SSH. Ponadto Coder obsługuje dzielenie się środowiskiem przez URL, co umożliwia programistom współpracę z projektantami nad rzeczywistym produktem zamiast zrzutów ekranu w PR-ach GitHuba.
• Aplikacje systemowe i wieloplatformowe można rozwijać łatwiej, ponieważ IDE jest uruchomione na systemie operacyjnym, dla którego robisz development. Model Coder OSS nie jest specyficzny dla Kubernetes i zamiast tego można udostępniać maszyny wirtualne.
• Sieci „air-gapped” to świetny przypadek użycia, ponieważ nie trzeba spędzać tak dużo czasu na bawienie się ze stacją roboczą. Zespół inżynierów spoza sieci może utworzyć obraz bazowy, który zostanie zaimportowany do sieci wewnętrznej. Jest to świetne rozwiązanie dla banków, służby zdrowia lub zastosowań wojskowych.

Podsumowanie

Zdalny rozwój szybko staje się alternatywą dla rozwoju lokalnego, a opieranie go o Kubernetesa wydaje się być najbardziej atrakcyjną wersją tego rozwiązania. Zespół inżynierów może z łatwością podwoić pojemność pamięci kontenerów swojego zespołu, ale podwojenie pamięci laptopa jest zbyt kosztowne. Bez względu na to, co próbujesz zrobić, aby zoptymalizować swój kod, finalnie i tak często jesteś zdany na łaskę Chrome lub pochłaniających zasoby narzędzi bezpieczeństwa.

Takie podejście umożliwia pełną hermetyzację wymagań konfiguracyjnych, co przynosi duże korzyści firmom, które mają do czynienia z historycznymi wydaniami lub starszym kodem. Model oparty o Kubernetesa umożliwia również skalowalność horyzontalną i wertykalną, zapobiegając sytuacji, w której deweloperzy są nieefektywni ze względu na „wydajność” maszyny, na której pracują. Ostatecznie zespół finansowy podziękuje ci za tańsze laptopy.

Podczas gdy zdalny rozwój od dawna jest powszechną praktyką dla gigantów oprogramowania, takich jak Google i Facebook, Coder OSS otworzył drzwi, aby uczynić go łatwo dostępnym dla firm każdej wielkości. Jeśli postępowałeś zgodnie z instrukcjami w moim repo, to mam nadzieję, że udało ci się zobaczyć to na żywo w mniej niż pół godziny.

Oryginał tekstu w języku angielskim przeczytasz tutaj.