LINUX.ORG.RU

Переоценен ли K8S/Docker с некоммерческой точки зрения?

 , , , ,


3

3

Привет всем,

Работаю с Docker/K8S еще с 2018 года. Примерно с того времени, все проекты как правило вертятся в рамках Kubernetes. Неважно как:

  • в виде managed-сервисов в облоках (GKE, AWS EKS)
  • в виде unmanaged на приватных bare-metal (через kubeadm)

Да, удобно. И прошу не закидывать данный сабж общими словами на тему:

  • Докер, это новый стандарт и удобный инструмент для сборки образов
  • что К8С удобен для быстрого поднятия сред и оркестрации приложений
  • что можно лимиты ставить, и решать проблемы зависимостей системных либ

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

Речь немного у другом. Я прочел недавно пост: https://lwn.net/Articles/676831/

И некоторые слова зацепили, как:

According to Walsh’s presentation, the root cause of the conflict is that the Docker daemon is designed to take over a lot of the functions that systemd also performs for Linux. These include initialization, service activation, security, and logging. «In a lot of ways Docker wants to be systemd,» he claimed. "It dreams of being systemd."

Сейчас, я выражу непопулярную точкую зрения :) и возможно, даже «мамонтовскую» :) но лезут такие мысли в голову:

  1. Докер действительно вызывает малость ощущения systemd-wanna be в опреденном аспекте, касаемо управления приложений (не берем аспект формирования образов)
  2. Формировать лимиты по RAM, CPU и др., вполне можно через тот же systemd
  3. Для проблемы эмуляции файловой ОС, совсем необяз. залезать в Docker, есть systemd nspawn и возможность дергать Linux namespaces напрямую
  4. честно говоря совсем банальная мысль :) а чем вам сама ОС не является крутым оркестратором для приложений?

Что мне лично еще не нравится при работе с Докером и К8С:

  1. Есть ощущения излишних слоев абстракций и user mode виртуализаций. С учетом того, что большинство приложений сидит на Java, Python, NodeJS … Спрашивается, а такая ли в этом необходимость? Куда ни шло, если речь про C++ проекты, где возня с headers/линковой либ и др., где действительно есть «головная боль» в ряде моментов… Но, на Жабке или Питоне-то? Сомнительно…

  2. Учет GAPов, если вы админите условный OpenStack с виртуалками и чудо-менеджер туда еще сует Докер, то создаются впечатления, что я занимаюсь больше обслуживанием абстракций, нежели реально проектом и реальной необходимости бизнесу

  3. Много какого-то ненормального хайпа вокруг этой облачно-контейтнерной тематики, и создается впечатление, что больше хайп ради хайпа. И менеджеры… Просто устраивают некий шоубизнес в IT на данной теме (сугубо личное мнение :) )

  4. Народ, как будто бы, разучился работать со stateful-сервисами и понимать проблематику больших баз и пр. Появилось много хомячков, кто трындит про A/B, удобное перекидывание контейнеров между нодами, но очень забавно было наблюдать :) как условные хомячки пытаются юзать Postgres в рамках контейнеров, а под капотом юзать Ceph (да еще в добавок на вирт. машинах), а потом удивляться, что кластер РСУБД не может быстро работать :) Уйму слоев виртуализаций построили, хранилища - дистрибутивные, проблему синхронизаций stateful-сервисов не решают, IOPS падает :) но зато «в облачке и поды по нодам». Понятно, что в облаках накинули 1000 баксов, и проблемы производительности могут улетучатся, ну или вообще увести базы в отдельные managed-сервисы. Но, очень забавляют картины, когда пытаются решать вопросы high load на приватных серверах через призму огромного слоя виртуализаций.

P.S. повторюсь, что сказал в начале. Спасибо Докеру и К8С за работу/деньги. Но, персонально есть ощущения какой-то лабуды. Как по мне, вполне себе можно было бы даже в условном systemd вращать многие приложения без огромной прослойки виртуализаций. Иногда кажется, что лучше быть не хайповым и вне моды.



Последнее исправление: twinpeaks (всего исправлений: 1)

Ответ на: комментарий от Harald

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

X512 ★★★★★
()

как условные хомячки пытаются юзать Postgres в рамках контейнеров, а под капотом юзать Ceph

Ну так а контейнеры тут причм? Просто головой слабы. Есть софт, который крутится внутри виртуализации, и есть софт, который должен быть максимально близко к железу. Ну что-то попутали, не в курсе, видно, что иные СУБД вообще свою фс на носителях имеют...

Shadow ★★★★★
()
Ответ на: комментарий от X512

Главное никогда не обновлять его, обновления безопасности не ставить, иначе глобальное состояние изменится!

Harald ★★★★★
()
Ответ на: комментарий от Shadow

Shadow ★★★★★ (07.09.21 02:31:15) Ну так а контейнеры тут причм?

Кое-что причем есть. Сейчас, хипстеры используют всякие:

Что уходит в тематику CAS (Container Attached Storage). Сейчас, видимо среди хипстеров - модно приседать на шпагу во время эксплуатации систем.

Ceph юзать вне контейнеров, на самом деле, тот еще квест. Добавлять еще Rook… В-общем, уже имел возможность видеть, как молодое поколение деплоит все возможные stateful-сервисы через призму:

  • helm charts/контейнеров
  • полностью доверять управление storage различным CAS, которые сырые и откровенно говоря опасны для PROD
  • во время фейла, обычно хипстота находится в шоке и не понимает как чинить тот или иной stateful-сервис, что логично… ведь же, не учили тонкости того, как управлять тот или иной managed-сервис в отдельности вне контейнеров

Помню время, когда блевались с DRBD. Но, современное хипстерское веяние тянет реально на какой-то новый уровень извращений, что при виде сего - атеисты начинают верить в Бога и карму.

twinpeaks
() автор топика

Что мне лично еще не нравится при работе с Докером и К8С:

Есть ощущения излишних слоев абстракций и user mode виртуализаций. С учетом того, что большинство приложений сидит на Java, Python, NodeJS … Спрашивается, а такая ли в этом необходимость?

Есть, так как эти виртуальные машины тоже иногда требуют нетривиальной настройки окружения. Но, в целом, есть и проблема хронического для индустрии NIH-синдрома (Not Invented Here). Вместо переиспользования существующих наработок люди склонны создавать что-то радикально новое. Не по идее, а по реализации.

Народ, как будто бы, разучился работать со stateful-сервисами и понимать проблематику больших баз и пр.

Хорошее наблюдение. Контейнерные технологии для существующих СУБД дают только лишний уровень абстракции и возможность потерять данные на ровном месте. Есть потуги сделать полноценные облачные (cloud native) СУБД, хорошо интегрированные с контейнерным стеком. Но они либо кустарны, либо закрыты. Поэтому хомячки будут продолжать вручную кастылять Постгрес в контенерах, а стратапы — пользоваться облачными БД и платить.

Сейчас docker и k8s — это возможность самому тонко контролировать окружение и иметь reproducible builds. Оно не так важно, когда у тебя один сервер в AWS гоняет твой хоумпейдж, но важно, когда у тебя тысячи различных VM-ок на попечении.

И ты прав, что без stateful services K8s неполноценен как стек разработки. Проблему смягчают облачные управляемые БД. Но фундаментальная для контейнерного опенсорса проблема в том, что никто не хочет писать «cloud native Postgresql».

aist1 ★★★
()
Ответ на: комментарий от anonymous

Пункт 3. Я, как жабобыдло, ищу работу в других сферах какраз из-за этого. Уж лучше с++ чем это.

Дели свою ЗП на 2, а лучше на 3. И готовься с важными видом деплоить с++ в k8s :)

aist1 ★★★
()
Ответ на: комментарий от MaZy

Про базы/хайлоад не совсем в тему. Оно друг другу никак не мешает, запускайте stateful вне кластеров/докера если это проще. Все по потребности

Как раз в тему. С данных все начинается и в них всё заканчивается. Stateful services требуют совсем другой парадигмы, чем stateless, и контейнеризация слишком сильно затачивается на последних. Вплоть до premature optimization.

aist1 ★★★
()
Ответ на: комментарий от twinpeaks

Не очень понял, кстати что есть cloud native.

И не поймешь, так как это слово ничего конкретного сейчас не обозначает. Есть AWS-native и k8s-native. И под cloud-native раньше понимали первое.

Чтобы твоя аппа была cloud-native, необходимо, чтобы данные она хранила в условном S3/DynamoDB, а весь процессинг делался на эфемерных нодах. На эфемерных нодах может храниться только кэш, который не страшно потерять, когда нода отстрелится по stock price.

Если же твоя аппа держит СУБД полностью на эфемерных узлах, то это не cloud-native. И если данные лежат на EBS, то это тоже не cloud-native. Это просто SAN.

Так вот, именно умение хорошо работать в модели object store <-> cache, делает дизайн cloud native. Потому что в облаке тебе принципиально не дают привязку машин к локальным дискам. Но зато тебе дают довольно таки дешевый object store (S3). Весь софт, которые подразумевает локальные диски — не cloud native.

Модель managed database тоже не является cloud native в изначальном понимании этого слова, так как БД предполагают обработку данных на своей стороне, что сильно повышает требования к ним в плане CPU. В результате полезная нагрузка переносится с эфемерных узлов на storage layer. Это обычный 3-tier, просто теперь банановый.

Условная cloud-native БД будет и SQL-джоины тоже делать на эфемерных узлах. Пример — PrestoDB.

aist1 ★★★
()
Ответ на: комментарий от MaZy

Задам вопрос по теме копеечных проектов тогда, не только вам, но и всем. С точки зрения удобства и RAD, стоит ли юзать докеры и к8сы для быстрого деплоя (учитывая что я и то, и другое только в туториалах видел)? Меня достало самому писать системд сервис-файлы, самому руками накатывать гит пуллы на инстансы, самому перезапускать их. Да и новый инстанс тоже надо конфигурить, ставить все зависимости, настраивать гиты. Проекты по инфра простейшие, но возни целая гора. Один вот на 4 инстанса разделен (так надо, нужны ip разных стран), так теперь каждый апдейт это зайди, запулли, конфиг доправь, перезапусти, логи чекни, поправь, запушь… х4, короче головняка на полчаса ради каждой фичи. Что мне делать? Я конечно вкурю и разверну и докер и к8с чтобы попробовать, но неохота время впустую тратить, если там аналогичная возня каждый раз.

Хотелось бы так: запушил мастер (или спец.ветку deploy) с дев-компа, на какой-то морде-дашборде поправил конфиги/апиключи, нажал «задеплоить», оно там само все запуллило, инстансы перезапустило, и там же я вижу все проблемы/логи.

И чтобы если новый инстанс, то на нем сделать лишь apt-get install wunder-waflya, и айпи инстанса с каким-нибудь ключом прописать в эту морду, и больше никогда на него не ходить руками.

anonymous
()
Ответ на: комментарий от anonymous

anonymous (08.09.21 10:36:28) С точки зрения удобства и RAD, стоит ли юзать докеры и к8сы для быстрого деплоя (учитывая что я и то, и другое только в туториалах видел)?

Удобство != стабильность. Если речь про всякие dev/test среды, то там пожертвовать стабильностью в сторону удобства - частая картина.

Хотя, я лично всегда против этого по банальной причине. Что потом, как правило, сводится к тому что нужно иметь PROD-like env для тестирования и получается, что удобно не будет в любом случае. Особенно, если проект становится старше и разрастается.

Когда, у тебя где-то 100 микросервисов и много баз под high load… Ну извини, не будет удобно, ну ни как…

Проекты по инфра простейшие, но возни целая гора. Если простейшие, то можно. Но где гарантии, что условно через полгода или год он не превратится в сложный? … так теперь каждый апдейт это зайди, запулли, конфиг доправь, перезапусти, логи чекни, поправь, запушь… х4

Ну, а почему не должно быть сложно? На самом деле, самое большое заблуждение современного IT, что сложность и проблемность проектов пытаются переложить на инфраструктуру. Когда, условно программисты говнокод делают, и их ПО работает «кое-как»…

Если условный программистик наговнокодил, то его ПО будет плохо работать, что в bare-metal, что в облаках.

Могу тебе сказать, что за последнее время заметил, что современные программистики уже не залезают в SQL и не пытаются оптимизировать базы, а начинают юзать подход «ORM/code first», где доверяют работу с базой - ОРМу вплоть до генерации всего (таблиц, индексов, SQL-запросов в runtime), где конечно знатно обсираются… Еще одно из больных мест с их code first - это миграции с РСУБД, и тут точно так же… Не важно, Докер-шмокер или облака/bare-metal, если ПО работает нестабильно, то инфра не столь важна… Проблемы искать надо в говнокоде программистиков.

И чтобы если новый инстанс, то на нем сделать лишь apt-get install wunder-waflya

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

  • влезать в Dockerfile, проводить оптимизации
  • влезать в Helm-chart шаблоны, делать в них фиксы и тестить их

И тут, ты поймешь, что с этой темой по мере разрастания проекта - overhead много и в плане рабочей деятельности. Тебя будет бесить то, что ты будешь тратить много времени на обслугу абстракций.

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 3)
Ответ на: комментарий от anonymous

Меня достало самому писать системд сервис-файлы

Точно так же, тебя достанет писать:

  • Dockerfile
  • docker-compose.yml
  • всякие k8s конфиги компонентов, их там на один контейнер можеть быть штук 6

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

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от twinpeaks

Если простейшие, то можно.

Вот мне и интересно, как? Цель уменьшить время на деплой и увеличить на разработку.

Но где гарантии, что условно через полгода или год он не превратится в сложный?

Ну я скажу «нахрен это», и все. У меня компания из одного меня в тех.плане, и если я сказал нет, значит чем-то другим займёмся. Но в целом проекты всегда простые, инхаус хелперы, автоматизация рутины, юзеров строго <= 10. Не бывает сложных заказов от тех, кто сами не сложные. Это у кровавых энтерпрайзов там фермы кластеров кубернетесов, а я хипстер апи-юзер, мне надо nmap :Deploy(), проверить и дальше код писать. И таких миллионы.

Это просто розовая мечта. Надо принять реальность

Я не из таких, мне НАДО, понимаешь? Я напишу себе waflyad.service и буду патчить конфиги через вебморду и заказывать инстансы по апи, но неужели этого никто еще не сделал? Если нет, это же оппортунити века.

anonymous
()
Ответ на: комментарий от anonymous

anonymous (08.09.21 19:12:51) Я не из таких, мне НАДО, понимаешь? Я напишу себе waflyad.service и буду патчить конфиги через вебморду и заказывать инстансы по апи, но неужели этого никто еще не сделал? Если нет, это же оппортунити века.

Да, сделали это все. Как ты сам пишешь тут:

У меня компания из одного меня в тех.плане, и если я сказал нет, значит чем-то другим займёмся. Но в целом проекты всегда простые, инхаус хелперы, автоматизация рутины, юзеров строго <= 10.

С таким описанием, то тебе вполне подходит. Я просто из мира более «кровавого enterpise» :)

В облаках можешь через какой-нибудь AWS EKS, GCP GKE - развернуть managed K8S-кластер. Можно добавить ряд продуктов от WeaveWorks поверх, у них есть аддоны. Короче, можно спокойно все это превратить в то, что ты хочешь. А если проект - мелкий и на уровне PoC/MVP , то подавно можно.

twinpeaks
() автор топика
Ответ на: комментарий от twinpeaks

Если условный программистик наговнокодил, то его ПО будет плохо работать, что в bare-metal, что в облаках

В облаке некоторые недостатки говнокода можно компенсировать легким масштабированием

annulen ★★★★★
()
Ответ на: комментарий от annulen

annulen ★★★★★ (08.09.21 21:42:44)

В облаке некоторые недостатки говнокода можно компенсировать легким масштабированием

Если еще ПО - готово к масштабированию. Частая картина, сейчас, что программистки не делают свое АПИ - идемпотентным. И что, в случае даже, scale x2 условное АПИ уже неспособно нормально работать.

twinpeaks
() автор топика
Ответ на: комментарий от anonymous

Докер - юзай, его стоит юзать вообще всегда. Мне сложно придумать ситуацию, когда докер не стоит использовать. А вот кубернетес - спорно. Тебе хватит docker-compose с головой.

PS когда я говорю докер, я в первую очередь имею в виду концепцию. В целом лучше использовать podman, чем докер. Но конфигурация одна и та же.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Legioner ★★★★★ (08.09.21 21:46:34)

Мне сложно придумать ситуацию, когда докер не стоит использовать. А вот кубернетес - спорно. Тебе хватит docker-compose с головой.

Ну, я не буду сейчас про:

  • stateful-сервисы
  • и что Docker - это SPOF, в контексте родительского процесса

Тем более, Вы сказали про «концепцию», поэтому тоже не очень понятно в какое русло идет Ваша мысль. Но, скажу что первое пришло в голову, когда прочел Ваш отрывок:

Мне сложно придумать ситуацию, когда докер не стоит использовать. А вот кубернетес - спорно.

А автомасштабирование по нодам (узлам), кто будет делать для Докер-контейнеров, если не условный К8С или OpenShift?

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 1)
Ответ на: комментарий от twinpeaks

stateful-сервисы

С ними никаких проблем в докере. Хочешь - вольюмы делай. Да и без вольюмов оно просто работает по умолчанию.

А автомасштабирование по нодам (узлам), кто будет делать для Докер-контейнеров, если не условный К8С или OpenShift?

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Legioner ★★★★★ (08.09.21 21:55:43)

С ними никаких проблем в докере. Хочешь - вольюмы делай. Да и без вольюмов оно просто работает по умолчанию.

«Да-да-да» , даже на офиц. Докер сайте есть страничка:

Где авторы самого Докера описывают возможные траблы с volumes у Докера. Не говоря про различные CAS-системы, которые работают поверх Докера (OpenEBS, Ceph Rook) и имеющие уйму траблов, аля:

Не говоря уж про след. списочек:

Который весьма ограничен. Почему К8С или Nomad привожу? Ну дык, различные CSI-драйвера, как раз юзают возможности Докерка для маунта вольюмов:

task «ceph-node» { driver = «docker» template { data = <<EOF

Да и человек, который юзал и OpenEBS и CephRook :) я тебе могу сказать что проблем - уйма.

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 1)
Ответ на: комментарий от Legioner

Legioner ★★★★★ (08.09.21 22:08:40)

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

Вы на Докере вращали процессы для той или иной РСУБД (Postrges/MariaDB), ну или даже NoSQL какой-нибудь (MongoDB, Elastic)? Пробовали всякие A/B-фичи, где часто надо переключать приложения, что в конце-концов передергивает поды и контейнеры, делая тот самый mount/umount частый?

Я после эксплуатации с OpenEBS и Ceph Rook остался очень недоволен. Асболютно лишний и ненужный допол. слой, под нагрузкой ты и вне контейнеров можешь на уровне host OS «веселуху» увидеть. Возьмем, к примеру требования по Постгри:

где, надо учитывать ряд kernel params, а тут еще доп. заноза в заднице в виде Докера, который ни к селу - ни к городу. Еще и наровит failure устроить, если нормально не размаунтиться… Так что не надо мне тут :)

P.S. : ну а в целом, нравится - юзайте. Но, мне не нравится и не советую Докер для тех, кому надо с базами работать или др. stateful-сервисами. Головной боли - больше, чем профита.

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 3)

Я вижу пользу докера в двух аспектах. Во-первых, это окружение. То есть, ты можешь легко воссоздать окружение продакшен-сервиса прямо на своём ноутбуке, в пару кликов. Это не отменяет тонких моментов вроде багов в самом докере или разных ядрах/настройках хост-машин, но покрывает львиную часть потребностей. Во-вторых, докер с кубернетесом помогают писать изначально масштабируемый софт и тестировать его опять же локально без поднятия десяти виртуалок или стэйджинг-кластера.

Самая большая проблема на данный момент — это стэйт. Я держу все продакшен базы на отдельных bare metal машинах, потому что есть админы и DBA, способные их сопровождать. Запихивание их в куб возможно технически, но не сильно понятен профит. И совсем не понятно, как это поддерживать с SLA в три девятки после запятой. Со стороны того же куба давно есть подвижки в эту сторону, но надежного софта, способного эффективно утилизировать эти подвижки, пока мало. Опыта сопровождения ещё меньше.

Ретроспективно это выглядит как хорошая попытка абстрагировать stateless сервисы. А стэйт решили закинуть на сдачу, лишь бы было.

filosofia
()
Ответ на: комментарий от filosofia

filosofia ★ (08.09.21 22:34:05)

Во-первых, это окружение. То есть, ты можешь легко воссоздать окружение продакшен-сервиса прямо на своём ноутбуке, в пару кликов.

Ноутбук потянет сотню контейнеров? :) У меня на фирме полное ПРОД окружение это свыше сотни микросервисов. Ну, я решил данную проблему так. Что у каждой команды свой скоуп микросервисов - размером в 10-20 микросервисов, где 100-140 - это чужие других.

Скажем так, проще… Сотня держится отдельно на отдельных серверах, а им программистикам - я подготовил вар-т равертывания через k8s single node - локально их 10-20 микросервисов (если программист на туксе - то у него развернут single k8s node с убраннами taints, если Windows/MacOS X , то через Vagrant, а в нем single k8s node та же). К базам и другим 100-140 микросервисом, они remotely подключаются к uat-среде, где есть копии баз с маск. данными и полноценной копии всего.

А у Вас как обстоят дела с этим?

Я держу все продакшен базы на отдельных bare metal машинах, потому что есть админы и DBA, способные их сопровождать. Запихивание их в куб возможно технически, но не сильно понятен профит.

Плюсую.

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 1)
Ответ на: комментарий от aist1

Дели свою ЗП на 2, а лучше на 3.

Это из-за смены деятельности или именно web --> non-web переход столько стоит?

И готовься с важными видом деплоить с++ в k8s :)

Не верю! Сишники смеются до коликов с каждой новой приблудой этих вебмакак.

untitl3d
()
Ответ на: комментарий от twinpeaks

Ноутбук потянет сотню контейнеров? :) У меня на фирме полное ПРОД окружение это свыше сотни микросервисов. Ну, я решил данную проблему так. Что у каждой команды свой скоуп микросервисов - размером в 10-20 микросервисов, где 100-140 - это чужие других.

Во-первых, под окружением я все же имел в виду юникс-окружение отдельного пода, версии библиотек, вот это все.

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

А у Вас как обстоят дела с этим?

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

Поэтому у нас чуть иначе. Разработчик технически может поднять все сервисы локально с тестовыми данными или даже подключиться к похожей на прод базе. Но обычно все ограничивается запуском одного, двух, трёх сервисов. Зачастую их можно даже запустить нативно без вагранта или докера, разрабатывать так как ни крути приятнее.

filosofia
()
Ответ на: комментарий от untitl3d

Не верю! Сишники смеются до коликов с каждой новой приблудой этих вебмакак.

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

filosofia
()
Ответ на: комментарий от untitl3d

Это из-за того, что область не хайповая, и денег там сильно меньше.

Не верю! Сишники смеются до коликов с каждой новой приблудой этих вебмакак.

Сишники сидят в своем пузыре. Что поделать, ну не пишут интернет-сервисы на Си. Писали бы, так сишники бодро бы осваивали все передовые технологии.

aist1 ★★★
()
Ответ на: комментарий от aist1

aist1 ★★ (08.09.21 23:27:20)

Сишники сидят в своем пузыре. Что поделать, ну не пишут интернет-сервисы на Си. Писали бы, так сишники бодро бы осваивали все передовые технологии.

У нас, кстати, Си используется :) Но, конечно там special case. Есть некоторые АПИ, которые на C/C++ работают с РСУБД только. Ключевые словa - backend API. Все остальное на Java. Java frontend APIs могут взаимодействовать с Сишным backend API через gRPC.

Но в целом, да. На ссях не пишут насегодня интернет-сервисы. Только в случаях, если совсем high load и критическое место для оптимизаций и не более. Но, у нас не только Си юзается, еще спецом Linux kernel тюнится на тачке с этими сервисами на Ссях.

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 2)
Ответ на: комментарий от untitl3d

untitl3d (08.09.21 22:59:21)

Это из-за смены деятельности или именно web –> non-web переход столько стоит?

Возможно вплоть до смены сферы. А что тебе веб так сдался на Ссях? :) У меня друзья, которые на Жабе и Шарпе долго сидят уже хотят уйти в системное программирование полностью.

Готовы, даже, сферу сменить с уменьшением з/п. Один устроился, но получает мало, сейчас. Ранее, он 350 тыс. рублей в месяц со своей Жабкой получал, сейчас 200 тыс. рублей в месяц на Ссях. Но, он сознательно пошел на понижение, чтобы заняться исключительно сферой системного программирования.

Сейчас пилит что-то в нашей рос. конторе, Postgres PRO.

twinpeaks
() автор топика
Ответ на: комментарий от aist1

Сишники сидят в своем пузыре. Что поделать, ну не пишут интернет-сервисы на Си. Писали бы, так сишники бодро бы осваивали все передовые технологии.

или наоборот, никаких «передовых технологий» не было бы, а веб быстро работал и грузился

Harald ★★★★★
()
Ответ на: комментарий от Harald

На сях сложно заметно ускорить что-то со стороны бэка или сети. Можно в несколько раз облегчить и упростить (с точки зрения системы), но именно ускорить сложно. А вот замедлить как раз легко.

filosofia
()
Ответ на: комментарий от filosofia

Вот, кстати, да. На том же C++ еще надо изрядно постараться, чтобы веб работал значительно быстрее, чем на Java. Можно, но уже не тривиально. В смысле, оно не обязательно будет работать быстрее только от того, что оно написано на С++. Поэтому на Java и пишут.

aist1 ★★★
()
Ответ на: комментарий от twinpeaks

Но, у нас не только Си юзается, еще спецом Linux kernel тюнится на тачке с этими сервисами на Ссях.

Там вам в ядро сейчас Rust впендюрят, чтобы «на Ссях не писали» :)

На плюсах веб-сервисы писать можно, и они будут вполне нормально работать в плане надежности. Проблема тут в тулинге. Ну неудобно это всё писать на С++ после опыта с Java и Python. А мазохистов нет. Точнее, есть, но их близко не подпускают, а то покалечатся.

aist1 ★★★
()
Ответ на: комментарий от aist1

Ну, у нас backend API на Ссях связано с финансами, базы с банкингом. Я не смогу уже тут техн. детали пояснить… Могу лишь сказать, что ранее пробовали эту часть на Java чисто ради эксперимента переписать. Оценили, что невозвоможно и бессмысленно.

Больших технических деталей не скажу, т.к. в целом их не знаю. Могу только сказать, что вот ровно АПИ работающие с Postgres написаны на Ссях, и они под очень высокой нагрузкой.

Все остальные АПИ - на Java у нас.

twinpeaks
() автор топика
Ответ на: комментарий от twinpeaks

Если у вас HFT, то да. На Java это или очень сложно и муторно, либо невозможно вообще. Зависит от SLA на задержки.

Проблема с Java в том, что высокопроизводительный код на нем уж очень сильно похож на С своей низкоуровневостью. И потерей безопасности памяти.

Я делал высокооптимизированные графовые движки в RAM на Java. Можно, работает, шустро. Ну лучше сразу на С++. Там это будет на много легче. Так и с веб-сервисами.

aist1 ★★★
()
Ответ на: комментарий от twinpeaks

А что тебе веб так сдался на Ссях? :) У меня друзья, которые на Жабе и Шарпе долго сидят уже хотят уйти в системное программирование полностью.

Не нужен мне веб на сях. Я тоже хочу в системное. Чтоб не видеть этих докеров-кубернетесов-девопсов. Я вот раньше считал spring корнем зла, так они и это переплюнули.

Про маленькие ЗП слабо верится. По началу мб, но синьор-помидор в intel или qualcomm врятли меньше зарабатывает, чем очередной девопсер. А работа куда интереснее.

untitl3d
()
Ответ на: комментарий от aist1

Причем тут веб-то? У сишников есть свои передовые технологии, куда долезла рука маркетологов. Например IoT и 5G. Но вот девопсов туда почему-то не завезли и каждые пол года новая тулза/фреймворк не появляется. А все потому что инженеры, а не эти, как их, ну ты понял.

untitl3d
()
Ответ на: комментарий от untitl3d

У меня для тебя плохие новости. Ты опоздал. Эмбеддед стремительно попсеет, порог вхождения снижается. Полным ходом идет автоматизация. Скоро туда завезут тонны хипсторов и девопсов. Бородатые пацанчики с аккуратными прическами будут между прошивками рассуждать об инклюзивности и социальной справедливости. Master/slave переименуют.

aist1 ★★★
()
Ответ на: комментарий от untitl3d

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

Вот чего там нет, так это «программирования в большом». То есть всех этих кодовых баз в сотни миллионов строк и гигабайтов зависимостей. Пока нет, но подвезут.

Я для себя проблему решил просто. Я тоже слышу внутри себя «зов железа», продирающийся ко мне сквозь слои виртуальных машин. Поэтому я купил себе FPGA и, когда душа зовет, дизайню RISC-V акселераторы для storage. Оставаясь при этом на непыльной работе джава-сеньера. Приятное, так сказать, с полезным.

Зато я теперь знаю, что для того, чтобы тупо два байта переслать из ячейки А в ячейку Б, процессору нужно выполнить уймищу работы. И что есть аппаратные акселераторы сборки мусора, а так же тегированная память. А еще можно аппаратно ускорять обмен сообщениями и таки наконец-то сделать микроядерные ОС эффективными, чего очень боится г-н Торвальдс.

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

Возможно, я неправильно выразился или ты про другое. Возможно, в IoT и есть бородатые смазливые пацанчики. Но я имел в виду самый low level. Тот, где протоколы передачи данных, где радио-инженеры, анетенны, например. Где RFC правит балом, а не product owner. Там бороды другие и люди тоже другие.

untitl3d
()
Ответ на: комментарий от aist1

Кстати, программирование для ARM (RISC) всегда было попсой ;-)

untitl3d
()
Ответ на: комментарий от untitl3d

Возможно, в IoT и есть бородатые смазливые пацанчики. Но я имел в виду самый low level. Тот, где протоколы передачи данных, где радио-инженеры, анетенны, например.

Cлишком поздно. Заметь, там на картинке написано Virtual Radio Machine.

Но если хочешь немного умеренного хардкора, мне нравится вот этот дерзкий проект. Это не радио, но тоже полезно. Это SmartNIC. Обработку трафика можно делать прямо в сетевой карте. Карта, правда, будет стоить $2.5K. Но прикольно. И уж железней некуда.

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 3)
Ответ на: комментарий от twinpeaks

Всем спасибо за инфу, попробую!

anonymous
()
Ответ на: комментарий от anonymous

У меня компания из одного меня в тех.плане, и если я сказал нет, значит чем-то другим займёмся.

Коллега. Все эти кубернетесы решают другие задачи. Если компания из одного Вас захочет предложить хостить некие сервисы компаниям, где есть полтора сотрудника, а одмина с руками найти не могут, то Вы вполне им можете предложить решение мышкой. Так же это для дирехтора заказчика снизит стартовые затраты деплоя и он скорее всего клюнет, не посчитав что будет потом. Хотя в/на потом он может и не смотрит ибо бизнес у нас сегодня не смотрит в завтравший день, точнее смотрит, но не все могут этот делать:)

Что касаемо тех тем, которые тут затрагивали, весьма красочно описывал тех представитель авиты, когда с кубернетисами они облажалиси и уговаривал сферического «Тебя» это не повторять:) Парсить тытрубу на предмет того линка, где они выбрасывали к8с лениво. Кто хочет найдет.

anonymous
()
Ответ на: комментарий от aist1

Сишники сидят в своем пузыре. Что поделать, ну не пишут интернет-сервисы на Си.

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

А вот отдельные крестоносцы, фром тайм ту тайм. Или как обьяснить существование и омг шевеление скажем такого прожекта, как https://www.webtoolkit.eu/wt

Так шта не стоит мыслить в парадигме тачпада.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.