Использование Coder-OSS для демонстрации возможностей сред разработки на основе Kubernetes.

Я десять лет руководил командами разработчиков инструментов. За это время я наблюдал взлеты и падения Vagrant, появление Docker и множества других инструментов сборки. Я помню, когда у большинства разработчиков под столом было два десктопа, и я помогал с массовым переходом на ноутбуки Mac. Я также помогал разрабатывать внутренние платформы для вычислений самообслуживания на AWS. Все эти инструменты были предназначены для того, чтобы приблизить рабочие среды к разработке и обеспечить простую настройку и масштабируемость локальной среды. Однако ни один из них не попал в точку.

После Palantir я поговорил со многими ведущими разработчиками. Оказывается, есть общие темы.

  • Многие разработчики страдают от низкой производительности своих ноутбуков. Это может быть связано с любой комбинацией плохо настроенных инструментов безопасности, тяжеловесных локальных процессов и, зачастую, с Chrome.
  • Большинство компаний борются с аргументом Mac, Linux или Windows. В большинстве случаев ИТ-команда застревает в подготовке всех трех компонентов. Всегда есть какой-то инструмент или библиотека, которые работают достаточно по-другому, чтобы вызвать проблему. Затем появляется что-то вроде чипа M1 от Mac, и начинается настоящий ад.
  • Внешним разработчикам сложно сотрудничать с UX-дизайнерами. Большинство компаний, особенно в этом отдаленном мире, не имеют хороших условий для совместной работы дизайнеров и разработчиков. Многие компании по-прежнему полагаются на скриншоты или короткие видеоролики для демонстрации новых компонентов пользовательского интерфейса — это ужасно.
  • Высокопроизводительные ноутбуки стоят дорого. Если у вас есть приложение, требующее больших вычислительных ресурсов, вы, вероятно, платите по 4 000 долларов США за каждого разработчика и еще по 4 000 долларов каждый раз, когда они напиваются и оставляют свой ноутбук в баре.

Но, честно говоря, ничто из этого не имеет значения по сравнению с этим:

  • Большинство инженеров не в восторге от местных условий. Скажите честно: вам нравится использовать свой ноутбук? Вам мешает ноутбук? Или уполномочить вас?

Если вы очень любите свой ноутбук и вам никогда не приходилось закрывать большинство ваших приложений, чтобы ваша проклятая встреча Teams не заикалась, то этот пост в блоге не для вас. Уходите.

Для удаленной разработки необходимо, чтобы все процессы сборки и тестирования выполнялись на удаленном компьютере, а ваш ноутбук выполнял функции браузера или тонкого клиента.

Хотите пропустить оставшуюся часть этой статьи? Вы можете просто перейти прямо к этому репозиторию GitHub и опробовать Coder OSS за 20 минут. Продолжайте читать, только если вы хотите узнать больше о том, почему удаленная разработка является превосходной средой разработки.

Если вам понравился этот пост, пожалуйста, 👏 , подпишитесь или подпишитесь на меня в среде или LinkedIn, чтобы сообщить мне, что я на правильном пути!

· Почему удаленная разработка лучше, чем локальная?
· Создайте экосистему удаленной разработки менее чем за 30 минут
· Какие типы проблем лучше всего решает удаленная разработка?

Почему удаленная разработка лучше, чем локальная?

Удаленная разработка значительно повышает продуктивность разработчиков

Основным аргументом в пользу удаленной разработки является то, что, перемещая рабочую нагрузку разработки на удаленный компьютер, вы можете перемещать, настраивать и масштабировать удаленный компьютер значительно быстрее, чем если бы вы распределяли новые ноутбуки среди своей группы разработчиков. Если удаленная машина оптимизирована для вашего варианта использования, она может выполнять следующие действия.

  • Увеличение скорости сборки и тестирования. Базовую виртуальную машину можно масштабировать и оптимизировать в соответствии с потребностями каждого отдельного проекта. В наших экспериментах мы добились скорости сборки с 9 минут до 2.
  • Уменьшение задержки. Разместив удаленную среду в правильном регионе, можно значительно сократить расстояние до своей инфраструктуры или облачных API. Для австралийского разработчика, работающего над инфраструктурой на востоке США, это улучшило несколько процессов в 10 раз.
  • Устранение трудоемких этапов настройки. В каждом репозитории есть этапы настройки, которые можно автоматизировать, что намного проще, когда вы контролируете рабочее пространство. Это особенно актуально для крупных организаций со старыми репозиториями. Автоматизируйте установку один раз и сэкономьте время всем.
  • Несколько сред. При выполнении крупного обновления библиотеки вы можете параллельно запустить вторую рабочую область для этого варианта использования. Это сохраняет изменения среды, позволяя вам продолжать писать код на основе исходной кодовой базы.

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

Kubernetes и удаленная разработка

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

Как показано выше, идея состоит в том, что у каждого разработчика есть свой постоянный том, но их базовый контейнер можно сделать эфемерным. Поскольку затраты на хранение составляют небольшую долю от общих затрат на вычисления, это позволяет разработчикам запускать действительно мощные контейнеры в течение рабочего дня, в то время как их компания тратит лишь копейки по вечерам и в выходные дни.

Верю ли я в то, что локальное развитие мертво?

Хорошо, хорошо — я на самом деле не верю, что он умрет, но не потому, что у меня есть очень убедительный аргумент. Крупные организации, такие как Google и Facebook, уже много лет используют модель удаленной разработки, но инструментарий OSS, делающий этот опыт лучше, потребовалось некоторое время, чтобы наверстать упущенное.

Самый разумный контраргумент заключается в том, что удаленная разработка не идеальна для разработчиков, работающих в регионах с нестабильным интернетом. Хотя это верно и сегодня, благодаря таким усилиям, как Starlink и ASTS, я считаю, что всего через пару лет доступ к глобальному Интернету станет реальностью для всех.

Второй наиболее разумный контраргумент касается опыта удаленной разработки набора IDE JetBrains. JetBrains выпустила Шлюз в 2021 году для решения этих проблем. К сожалению, Gateway от JetBrains поначалу работал грубо, и я бы не рекомендовал его постоянным пользователям IntelliJ или Webstorm. Однако за последний год он значительно продвинулся вперед, и я ожидаю, что в течение 1–2 лет пользователи сочтут его эквивалентом локальной разработки.

Откровенно говоря, основные сомнения связаны с отсутствием веры в то, что IDE на основе браузера будет приемлема для разработчика, работающего полный рабочий день. Он должен быть медленным, сложным в использовании, ненадежным или чем-то неприятным, верно?

Вот где сияет CoderOSS. Это бесплатный способ увидеть, каким может быть опыт удаленной разработки для ваших разработчиков. Попробуйте сами - лучший способ.

Разверните экосистему удаленной разработки менее чем за 20 минут

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

Инструкции по установке Coder:

Вся настройка займет у вас менее 10 минут, хотя, если вы новичок в Google Cloud, это может занять у вас немного больше времени.

Инструкции по настройке кодера:

  • Перейдите к IP-адресу балансировщика нагрузки (Google Cloud/Kubernetes Engine/Services & Ingress.
  • Создайте исходное имя пользователя и пароль.
  • Перейдите в Templates/Kubernetes/Create Workspace и дайте рабочему пространству имя.
  • Через три минуты вы должны увидеть это:

  • Нажатие «code-server» должно открыть новую вкладку браузера с VSCode, работающим в удаленной системе.

Не уверен насчет вас, но меня это поразило, когда я впервые увидел его в действии. Я привык к миру Windows RDP или VNC, и идея использовать мой браузер в качестве постоянной IDE казалась уловкой. Однако, увидев его в действии, я был продан.

Какие типы проблем лучше всего решает удаленная разработка?

В течение многих лет руководя командой опытных разработчиков и искренне веря в DevOps (по крайней мере, DevOps, описанный в Проекте Феникс), я могу сказать, что, хотя оптимизация рабочего пространства вашей компании важна, она может быть не самой важной для вас задачей. важная проблема. Если какая-либо из проблем, перечисленных ниже, является одной из ваших главных проблем, стоит изучить возможность удаленной разработки.

Проблемы, которые хорошо подходят для удаленной разработки

  • Длительное время сборки, выполнения или тестирования (›5 минут) обычно ограничено некоторым сочетанием вычислительных ресурсов, памяти, диска, сети, задержки или даже операционной системы. Все это можно настроить с помощью модели удаленной разработки и делать это в каждом конкретном случае.
  • Внесение исправлений в старый код может занять много времени, если инженеру необходимо настроить свою локальную рабочую станцию ​​для работы с историческими версиями, устаревшим кодом или просто кодовыми базами, к которым редко обращаются. Если вы заключаете среду в контейнер, установка больше не выполняется вручную и ограничивается только временем загрузки контейнера. Кроме того, такие инструменты, как Coder, поддерживают развертывание нескольких сред для каждого разработчика, что позволяет им развертывать выделенные среды для исправлений, не прерывая их текущую работу.
  • Защита исходного кода (т. е. изолированная) необходима, когда вы имеете дело с правилами (т. е. ITAR), финансовыми системами или системами, критически важными для безопасности. Многие из этих организаций стремятся полностью изолировать свои ресурсы, чтобы предотвратить утечку исходного кода. Гораздо сложнее обслуживать изолированные ноутбуки для разработки, чем удаленный контейнер для разработки.

Типы разработки, которые хорошо подходят для удаленной разработки

  • Фронтенд-разработка может заметно повысить производительность разработки за счет увеличения объема вычислений/памяти, а VSCode (самая популярная IDE для фронтенд-разработки) очень хорошо работает с удаленной разработкой из-за кодера/кода. -server» и его способность выполнять удаленный бэкенд по SSH. Кроме того, Coder поддерживает URL-адреса удаленных разработчиков, которые позволяют разработчикам сотрудничать с дизайнерами над реальным продуктом, а не с помощью скриншотов в PR GitHub.
  • Разработку ядра или любой кросс-операционной системы можно улучшить, потому что вы запускаете IDE в операционной системе, для которой вы пытаетесь разработать. Модель OSS Coder не специфична для Kubernetes, и вместо этого вы можете выделить виртуальные машины.
  • Сети с воздушным зазором — отличный вариант использования, поскольку вам не нужно тратить столько времени на возню с рабочей станцией. Группа инженеров за пределами сети может создать базовый образ, который будет импортирован во внутреннюю сеть. Это отлично подходит для банков, здравоохранения или военных целей.

Заворачивать

Удаленная разработка быстро становится альтернативой локальной разработке, и модель Kubernetes кажется наиболее привлекательной версией этого. Команда инженеров может легко удвоить емкость памяти контейнеров своей команды, но удвоение памяти их ноутбука обходится слишком дорого. Независимо от того, что вы пытаетесь сделать для оптимизации своего кода, в конце концов вы часто оказываетесь во власти Chrome или ресурсоемких инструментов безопасности.

Модель удаленной разработки Kubernetes поощряет полную инкапсуляцию требований к разработке, что приносит большие дивиденды компаниям, которым приходится иметь дело с историческими выпусками или устаревшим кодом. Модель Kubernetes также обеспечивает горизонтальную и вертикальную масштабируемость, предотвращая неэффективность ваших разработчиков из-за «производительности». Наконец, ваша финансовая команда поблагодарит вас за более дешевые ноутбуки.

В то время как удаленная разработка уже давно является обычной практикой для таких гигантов программного обеспечения, как Google и Facebook, Coder OSS открыл двери, чтобы сделать его легко доступным для компаний любого размера. Если вы следовали инструкциям в моем репозитории, вы, надеюсь, смогли увидеть это своими глазами менее чем за 30 минут.

Надеюсь, вам понравился этот пост. Если вы это сделали, пожалуйста, похлопайте, подпишитесь на меня или нажмите на LinkedIn, чтобы сообщить мне, что я попал в точку.