Обновить
296
0
Дмитрий Шурупов@shurup

Open Source geek

Отправить сообщение
Мы начинали с того, что ограничений на дистрибутив не ставили. Но это принесло больше сложностей, чем реальной потребности. Не теория (все линуксоиды любят разные дистрибутивы, многие не любят конкретно Ubuntu, …), а конкретный опыт расходится с тем, чтобы «75% пользователей не устроило». Уже и не вспомню, когда в последний раз такой вопрос всерьёз поднимался…
Мы очень активно используем онлайн-встречи (Google Meet), не только для регулярных командных «заседаний», но и обсуждения решения конкретных задач: от срочного инцидента до плановых работ или там передачи знаний в духе «помогите разобраться вот с такой проблемой, кто уже делал» (если нет во внутренней документации, конечно).

Плюс, я уверен, что работают у нас всё-таки довольно специфичные люди, во многом гораздо лучше «ориентированные на текст», чем среднестатистический человек, у которого действительно эффективность может раз в 10 упасть…

Вообще же, путь наш от офисов к удалёнке был долгим и непростым. Много лет ушло на то, чтобы многие нюансы (в частности, по той проблеме, что здесь озвучена) всплывали, понимались, преодолевались… пока не подошли к замечательной нынешней эпохе, когда можем себе позволить всех нанимать на удалёнку. Безусловно, нюансы и по-прежнему бывают, но они уже точно не влияют так сильно на эффективность ­— иначе мы бы банально не выжили (= адекватный результат для клиентов не приносили, людей подходящих не набирали, etc).
У нас особые «пользователи» + мы с самого основания компания, занимающаяся только GNU/Linux. Но даже при всем этом мы теперь сдались сдвинулись в сторону добавления к этому списку macOS.
В реальности у нас бывает и больше. Мы за это платим, конечно.
Не скажу за других, но мы, занимаясь как раз-таки обслуживанием Kubernetes, наличие такого опыта не считаем обязательным. Главное — это всё же хорошая база, общие навыки/качества для того, чтобы погрузиться в нужное.
Но ведь есть и варианты удаленной работы в качестве DevOps-инженеров. У нас, например, работают люди из многих регионов.
Вот, кстати, еще утилита появилась: github.com/alexlokshin/kube-entropy
> Simplistic chaos engineering tool for kubernetes application resilience testing
Если бы Kubernetes не был стандартом де-факто для запуска тех самых [микро-]сервисов, о которых речь, то можно было бы и подумать про clickbait, а так могу лишь оставить это на ваш вкус (точнее, ваше отношение к K8s).
Не реклама, а контекст. В статье неоднократно упоминается Kubernetes как окружение, в котором запускаются приложения с перечисленными («добавленными») факторами, а ещё она находится в соответствующем хабе (помимо прочих).

Вам не надо, но почему вы за всех? Авторы вот за всех не говорят, а явно обозначают, для кого. В вводное примечание добавили ещё раз про Kubernetes, чтобы убрать остатки возможного диссонанса.
Очень слабые советы. Если конкретнее, то:

  1. completion для kubectl — азбука;
  2. про kubectl-aliases писали, например, здесь (2 года назад), где были другие интересные проекты по теме;
  3. Helm — даже прокомментировать сложно. Это не tip, не trick, а очевидный инструмент. И такой «мануал» по нему — кхе-кхе…
Оркестровка — это «изложение музыки для исполнения её каким-либо составом оркестра или инструментальным ансамблем». А ещё в русскоязычной wikipedia устоялся именно такой термин, и лично мне он более симпатичен. Но ради чего спор?

По аналогии с "обычным" дистрибутивом для Enterprise будет Red Hat CoreOS. Это анонсировали ещё год назад: https://coreos.com/blog/coreos-tech-to-combine-with-red-hat-openshift


"Red Hat CoreOS is expected to integrate concepts, technology, and the user experience of Container Linux. This offering is intended to ultimately supersede Atomic Host and function as Red Hat’s immutable, container-centric operating system."


Ну, и дальнейший (основной) фокус на том, что для настоящего enterprise вообще не эти инфраструктурные фрагменты, а OpenShift во всей красе, куда в конечном счёте оно и интегрируется.

Должно быть понятно, что Fedora Atmoic Host и Container Linux больше не будет. Вместо обоих проектов теперь один — Fedora CoreOS.

Не стоит думать, что основная нагрузка (столь заметная на условном ноутбуке) создаётся самой системой Kubernetes, а не запущенными в ней workloads.
Вы про быстрый и автоматизированный деплой изменений в приложении в удалённый кластер или какую идею? Почему?
Если болид Ф1 не стоит запускать на пересеченной местности российской деревни, то не стоит его запускать нигде? Чем вы руководствуетесь, заявляя подобное?
1. Факт такого обращения уже означает, что гарантий нет, вот и все. Если это, опять же, не какой-то особо достоверный источник, создаваемый не корпорацией со своими целями, а на всеобщее благо с независимым, открытым управлением и т.п.

2. Хоть и бывают всякие исключения, в целом здесь есть прямые зависимости, и происхождение их в области изначальных побуждений (это зарабатывание денег, что очень нормально и я совсем не осуждают для коммерческих организаций, или что-то ещё).

В целом, уже далеко куда-то уходим — думаю, каждый выводы сам сделает :-) Достаточного оправдания для огульного выпада против существующих браузеров лично я не увидел, а разговоры «Open Source тут ни при чем» могут быть интересными, конечно, но только уводят от сути.
Open Source здесь при том, что:
1) полностью открытые исходники позволяют убедиться в правдивости заявлений (собирают ли сведения о пользователях и какие);
2) их разрабатывают не корпорации, а некоммерческие организации/сообщества с чуть другими идеалами, чем заработать любыми средствами (не все компании такие, конечно, но именно потому и написал особенно, что тут вероятнее, а с первым фактором — ещё и проверяется…).

Странность в том, что вас спрашивают: почему не стать Open Source. Вы отвечаете: потому что у нас другая модель, чем Open Source, в ней профессиональные оплачиваемые разработчики. А я пытаюсь уточнить, в чем она другая, если в Open Source (в крупном) тоже профессиональные и оплачиваемые. Не в этом же суть вашего отличия.

Поверить в то, что сегодня какой-то сервис смог бы выжить, полностью отказавшись от «торговли» сведениями о своих пользователях, довольно сложно

Без конкретных, развернутых фактов, — особенно в сравнении с Open Source-проектами — это заявление выглядит очень некрасиво: какие все-все плохие, а только мы хорошие. Можно и без подобных обвинений замечательно написать о том, чем же компания зарабатывает.

Информация

В рейтинге
Не участвует
Откуда
Таиланд
Работает в
Зарегистрирован
Активность