Розвиток ноутбуків мертвий: чому віддалена розробка – це майбутнє

Розвиток інструментів для розробки

Я провів десять років у керівництві командами розвитку інструментів. Протягом цього часу я спостерігав за стрімким зростанням та спадом популярності Vagrant та запровадженням Docker та безліччю інших інструментів для збірки. Я пам'ятаю, коли більшість розробників мали під своїми столами два настільних комп'ютери, і я допомагав у переході на ноутбуки Mac. Також я допомагав у розробці внутрішніх платформ для самообслуговування обчислень на AWS. Усі ці інструменти мали на меті наблизити виробниче середовище до розробки та забезпечити просту конфігурацію та масштабованість локального середовища. Проте жоден з них не зміг досягти цієї мети.

Після Palantir я спілкувався з багатьма керівниками досвіду розробника. Виявилося, що є деякі загальні теми:

• Багато розробників стикаються з поганим продуктивності на своїх ноутбуках. Це може бути викликано будь-якою комбінацією погано налаштованих засобів безпеки, важких локальних процесів, і, часто, Chrome як великий потрібник ресурсів.
• Більшість компаній мають проблеми з аргументом Mac проти Linux проти Windows. У більшості випадків, ІТ-команда застрягає в наданні трьох варіантів. Завжди є якийсь інструмент чи бібліотека, які працюють настільки по-різному, що викликають проблеми. А потім виходить щось подібне до чіпу M1 для Mac, і починається анархія.
• Фронтенд розробники мають проблеми зі співпрацею з дизайнерами UX. Особливо в цьому віддаленому світі, більшість компаній не мають добрих налаштувань для співпраці дизайнерів та розробників. Багато компаній все ще покладаються на знімки екрану або короткі відеоролики для демонстрації нових компонентів користувацького інтерфейсу - відразливо.
• Дорогі продуктивні ноутбуки. Якщо у вас додаток, який вимагає значних обчислень, ви, ймовірно, витрачаєте $4 тисячі на розробника, і ще $4 тисячі, кожного разу, коли вони нап'ються і забуть свій ноутбук в барі.

Проте, чесно кажучи, нічого з цього не стосується цьому:

• Більшість інженерів не в захваті від своїх локальних середовищ.

• Будьте чесні: чи знаходите ви задоволення від роботи на своєму ноутбуці? Чи заважає вам ноутбук? Чи дає вам силу?

Якщо ви абсолютно обожнюєте свій ноутбук і ніколи не доводилося закривати більшість програм, щоб забезпечити безперервність свого зустрічі Teams, то цей пост для вас не буде цікавим. Прощайте.

• Віддалена розробка передбачає використання віддаленого комп'ютера для виконання всіх процесів збірки та тестування, під час якого ваш ноутбук служить лише веб-браузером або легким клієнтом. *

• Хочете пропустити читати решту цієї статті? * Ви можете просто перейти прямо до цього GitHub Repo і спробувати Coder OSS за 20 хвилин. Продовжуйте читати лише тоді, якщо ви хочете дізнатися більше про те, чому віддалена розробка є кращим середовищем для розробки.

Якщо вам сподобався цей пост, будь ласка, поставте 👏, підпишіться, або слідкуйте за мною на medium або LinkedIn щоб дати знати, що я йду в правильному напрямку!

• Чому віддалена розробка краща за локальну розробку?
• Запустіть екосистему віддаленої розробки за менше ніж 30 хвилин
• Які проблеми найкраще вирішує віддалена розробка?

Чому віддалена розробка краща за локальну розробку?

• Віддалена розробка значно підвищує продуктивність розробника *

Основна аргументація на користь віддаленої розробки полягає в тому, що, переміщуючи навантаження розробки на віддалений комп'ютер, ви здатні значно швидше переміщати, налаштовувати та масштабувати віддалений комп'ютер, ніж могли б розподілити нові ноутбуки вашій розробницькій команді. Якщо віддалений комп'ютер оптимізований для вашого використання, він може робити наступне.

• * Покращити швидкість збірки та тестування: * Основна віртуальна машина може бути масштабована і оптимізована для відповідності потребам кожного окремого проекту. У наших експериментах ми зменшили час збірки з 9 хвилин до 2.

Основні переваги віддаленого розробництва

• Зменшення затримок: Розмістивши своє віддалене середовище у відповідному регіоні, можна значно скоротити відстань до інфраструктури або хмарних API. Наприклад, для австралійського розробника, який працює з інфраструктурою, розміщеною на US East, це поліпшило кілька процесів у 10 разів.

• Елімінація часомістких кроків налаштування: У кожному репозиторії є кроки налаштування, які можна автоматизувати, особливо легше, коли ви контролюєте робоче середовище. Це особливо актуально для великих організацій зі старими репозиторіями. Автоматизуйте установку один раз, і зекономте час усім.

• Декілька середовищ: Під час важливого оновлення бібліотеки можна запустити друге робоче середовище паралельно для цієї задачі. Це дозволить зберігати зміни в середовищі в межах контрольованого простору, щоб ви могли продовжувати писати код на базі вихідного коду.

Я спочатку дізнався про цю модель у інженера, який використовував code-server (зверніть увагу на 57 тис. зірочок) на віддаленій віртуальній машині. Його основною проблемою було те, що він не міг перевірити та зібрати великий вихідний код через те, що його ноутбук був настільки завантажений захисними інструментами, що його IDE впадав. Моєму розумові було (від цього) вибухнуто, але я зрозумів, що ця модель не має шансів масштабуватися. Віртуальні машини можуть бути дуже дорогими, і запуск одного або кількох середовищ на розробника був би нерозумним. Розробникам потрібно мати своє середовище увімкненим лише під час робочих годин, і цей тип використання ідеально підходить для Kubernetes.

Kubernetes та віддалене розробництво

Розгортання віддалених робочих середовищ як Kubernetes підчинок вирішило мої проблеми з витратами та налаштуванням. Я міг контролювати середовище виконання, базові образи та практики безпеки, і можна було скористатися економічними перевагами, масштабуючи вгору та вниз потужність обчислення, коли розробники починали та закінчували свої робочі дні.

Як зображено вище, ідея полягає в тому, що кожен розробник має свій власний постійний обсяг, але їхній базовий контейнер може бути тимчасовим.

З огляду на те, що витрати на зберігання є лише невеликою часткою від загальних витрат на обчислення, це дозволяє розробникам запускати потужні контейнери під час робочих днів, тоді як їхні компанії витрачають лише копійки вечорами та вихідними.

Чи справді вірю я, що локальна розробка померла?

Добре, гаразд – я насправді не вірю, що вона вмирає, але не через те, що у мене є дуже переконливий аргумент. Великі організації, такі як Google та Facebook, використовують віддалену модель розробки вже множину років, але відкрите програмне забезпечення для забезпечення зручного досвіду тривало випереджувало.

Найбільш розумним контраргументом є те, що віддалена розробка не є ідеальною для розробників, які працюють у місцях з нестійким Інтернетом. Хоча це правда сьогодні, зі спробами, такими як Starlink та ASTS, я вважаю, що віддалений доступ до Інтернету стане реальністю для всіх упродовж кількох наступних років.

Другим найбільш розумним контраргументом є досвід віддаленої розробки для пакету IDE від JetBrains. JetBrains випустила Gateway в 2021 році, щоб вирішити ці проблеми. Нещодавно Gateway від JetBrains був недоробленим, і я не рекомендував би його для постійних користувачів IntelliJ або Webstorm. Однак за останній рік він зробив значний прогрес, і я очікую, що через 1–2 роки користувачі вважатимуть його еквівалентним локальній розробці.

Чесно кажучи, головне коливання полягає у тому, що відсутні віра, що IDE на основі браузера буде прийнятною для повноцінного розробника. Вона повинна бути лагодженою, важкою у використанні, ненадійною або щось інше неприємне, чи не так?

Ось де виявляється справжній потенціал CoderOSS. Це безкоштовний спосіб переконатися, яким може бути досвід віддаленої розробки для ваших розробників. Спробуйте це самі – найкращий спосіб.

Запуск віддаленої розробки у власній екосистемі менше, ніж за 20 хвилин

Я створив простий у використанні репозиторій як демонстраційний шлях, щоб показати, як виглядає віддалений Visual Studio Code на Kubernetes. Я обрав хмарну службу кластерів Google, оскільки вони пропонують кредит на $300 та GKE Autopilot, який дуже легкий у використанні.

Інструкції по встановленню Coder:

• Створіть обліковий запис Google Cloud, проект та обліковий запис служби у цьому проекті з дозволом редактора.
• Розгалужуйте мій репозиторій та налаштуйте його за допомогою spacelift.io або еквіваленту.
• Встановіть GOOGLE_CREDENTIALS та TF_VAR_project з ідентифікатором проекту зверху.
• Виконайте і застосуйте Terraform.

Вся установка повинна зайняти у вас менше 10 хвилин, хоча якщо ви новачок у Google Cloud, це може тривати трохи довше.

Інструкції по налаштуванню Coder:

• Перейдіть за IP-адресою балансувальника навантаження (Google Cloud / Kubernetes Engine / Services & Ingress).
• Створіть початкове ім'я користувача та пароль.
• Перейдіть до Templates / Kubernetes / Створити Робочий простір та дайте робочому простору назву.
• Протягом трьох хвилин ви повинні побачити це:

• Натискання на 'code-server' повинно відкрити нову вкладку браузера з VSCode, який працює на віддаленій системі.

Не знаю як вам, але це мене вражає вперше, коли я побачив це в дії.

Я звик до світу Windows RDP або VNC, і ідея використання мого браузера як постійної Інтегрованої Середовища Розробки (IDE) здалася маркетинговим трюком. Проте, після того, як я побачив це на дії, я був проданий.

Які проблеми найкраще вирішує розробка на віддаленому сервері?

Будучи керівником команди розробників протягом багатьох років і відданим прихильником DevOps (принаймні, як це описано у Phoenix Project), я можу сказати, що, хоча оптимізація робочого простору розробників вашої компанії важлива, це можливо не є вашою найважливішою проблемою. Якщо будь-яка з проблем, перерахованих нижче, є однією з основних, то варто розглянути можливість використання віддаленої розробки.

Проблеми, для яких розробка на віддаленому сервері добре підходить

• Довгі часи збирання, виконання або тестування (>5 хвилин) зазвичай обмежені певною комбінацією ресурсів, таких як обчислення, пам'ять, диск, мережа, затримка або навіть операційна система. Усі ці аспекти можуть бути налаштовані за допомогою моделі віддаленого розвитку і можуть бути вирішені індивідуально.
• Виправлення старого коду може займати багато часу, якщо інженер повинен налаштувати свій місцевий робочий стіл для роботи з історичними версіями, легасі-кодом або просто рідко використовуваними кодовими базами. Якщо ви увігнездите середовище в контейнер, налаштування вже не буде вручним і буде обмежено лише часом завантаження контейнера. Крім того, такі інструменти, як Coder, підтримують запуск кількох середовищ на розробника, що дає змогу створювати окремі середовища для гарячих виправлень без завадження їх поточної роботи.
• Захист вихідного коду (тобто повітряно-ізольований) необхідний, коли ви маєте справу з правилам (таким як ITAR), фінансовими системами або системами критичної для безпеки. Багато з цих організацій прагнуть до повного ізоляції для запобігання витоку вихідного коду. Гораздо складніше підтримувати ноутбуки для розробки з ізольованими від мережі системами, ніж підтримувати віддалений розробний контейнер.

Типи розробки, які гарно підходять для віддаленої розробки

• Фронтенд розробка може побачити значне зростання продуктивності розробки завдяки збільшенню обчислювального потенціалу та пам'яті, а VSCode (найпопулярніше IDE для фронтенд розробки) добре працює з віддаленою розробкою завдяки coder/code-server та його можливості виконувати віддалену зв'язок з сервером через SSH. Крім того, Coder підтримує віддалені URL-адреси для розробки, що дозволяє розробникам співпрацювати з дизайнерами над фактичним продуктом, а не через знімки екрану в GitHub PRs.
• Ядро або будь-яка крос-операційна система розробки може бути покращена, оскільки ви запускаєте IDE на операційній системі, для якої ви намагаєтеся розробити. Модель Coder, спрямована на Kubernetes, не є специфічною для Kubernetes, і ви можете створювати віртуальні машини замість них.
• Мережі, що відсутні з'єднання з мережею - відмінний варіант, оскільки вам не потрібно витрачати так багато часу на конфігурацію робочої станції. Інженерна команда за межами мережі може створити базовий образ, який потім імпортується во внутрішню мережу. Це дуже корисно для банків, сфери охорони здоров'я або військових випадків.

Підсумок

Віддалена розробка швидко стає альтернативою локальній розробці, і модель Kubernetes, схоже, є найбільш привабливою версією. Інженерна команда може легко подвоїти обсяг пам’яті своїх контейнерів, але подвоєння пам’яті ноутбуку є надто дорогим заходом. Незалежно від того, як ви намагаєтесь оптимізувати свій код, у кінці кінців часто ви застрягаєте на волю Chrome або ресурсозатратних інструментах безпеки.

Модель віддаленої розробки Kubernetes стимулює повне уподібнение вимог розробки, що приносить значні вигоди компаніям, які мають справу з історичними випусками або легасі кодом. Крім того, модель Kubernetes дозволяє горизонтальне і вертикальне масштабування, запобігаючи невдачам ваших розробників через "продуктивність".

"Нарешті, ваша фінансова команда подякує вам за дешеві ноутбуки.

Хоча віддалений розробка давно є поширеною практикою для гігантів програмного забезпечення, таких як Google та Facebook, Coder OSS відкриває двері для доступу до цього навіть для компаній будь-якого розміру. Якщо ви слідували інструкціям у моєму репозиторії, ви могли надіятися бачити це в дії самі за менш ніж за 30 хвилин.

Сподіваюся, вам сподобалась ця публікація. Якщо так, будь ласка, натисніть аплодувати, підпишіться або зв'яжіться зі мною в LinkedIn, щоб дати знати, що я вразив ціль."