В этом сценарии - несоизмеримо дешевле (почти наверняка бесплатно). А в целом сравнивать можно, если иметь чуть больше данных. Как правило, с serverless сервисами работает подход - если нагрузка плавающая и не очень хорошо прогнозируемая, то их использование часто будет дешевле.
Если нагрузка постоянная и хорошо прогнозируется, то экономическая целесообразность serverless считается заметно сложней, через TCO и потенциальную экономию в процессах разработки, а не в явном виде в инфраструктуре.
Да ну, бросьте, о каком неуважении речь. Я бы вообще не сказал, что у управленцев может быть понятие «впахивать».
В случае менеджеров, можно работать много и постоянно быть в рабочем тонусе, просматривать почту, отвечать на задачи в джире, что-то придумывать, записывать куда-то идеи — это все будет называться, по крайней мере в моем мире, — работать.
При этом, конечно же, я более чем согласен с комментариями выше: при выполнении задач требующих максимальной концентрации (например, будучи разработчиком) — невозможно выполнять их с одинаковым и приемлемым уровнем качества в течении продолжительного времени.
Ты не делаешь подряд сформулированные задачи, где тебе нужен фокус. Ты постоянно держишь в голове всю картинку в целиком, выделяя на те же самые конкретные задачи строго определенное время максимальной концентрации.
Является ли это временем потраченным на работу? Да. Является ли это следствием неэффективности? Нет. Это вообще не про то.
Конкретных бенчмарков мы, честно, не делали.
GitLab нужно как минимум 2 Гб памяти, если мне не изменяет память. Gogs неплохо работает на самых простых конфигурациях с 512 памяти в Vscale. Правда стресс-теста с огромным кол-вом реп я не делал.
Ну про команду никто вроде и не говорил, как обязательную опцию.
Ну и плюс держать репозиторий локально не все готовы. Gogs на текущий момент — хорошая, производительная и легкая альтернатива ресурсоемким GitLab, RHC, Stash и прочим self-hosted решениям.
Может вполне использоваться, как приватный репозиторий. Ну а в будущем, думаю, у них появится и кодревью (pre-merge) и сниппеты. Все это обсуждается.
Ревью доступен и в обычной версии, не только enterprise. Как он организован:
https://about.gitlab.com/2015/08/05/6-reasons-why-pre-is-better-than-post-production-code-review/
Мысль я понял, конечно же, принимаю не на свой счет.
Есть ряд нюансов:
— Все пакеты нужно где то хранить и обновлять
— Чем больше пакетов ставить — тем больше ставится скалет
— Не все кейсы нужны кому то, кроме пары человек
Все это накладывает ограничения. В том числе, например, образ с WordPress или образ с GitLab — ставится не на все тарифные планы. Тут тоже имеет место прежде всего возможность гарантированно стабильной работы на выбраном конфиге для большинства пользователей. Понятно, что немного подтюнив сервер (установить ngnix для статики, отказаться от apache, подключить swap раздел) — можно установить и на меньшие конфигурации, но все это требует тонкой настройки, которая индивидуальна в большинстве своем.
Сейчас есть возможность увидеть все фичи после основной регистрации (активация по ссылке из почты). В целом — это достаточно быстро и удобно. Если все понравится — активируете учетную запись полностью (смс и привязка карты).
Но за отзыв — спасибо, о проблеме знаем и работаем над этим ( и в принципе над публичным сайтом ).
Готовые образы — это прежде всего попытка угодить всем. Универсальное решение, подходящее в абсолютном большинстве случаев.
Поэтому, конечно, порой действительно все равно нужно пойти на сервер по ssh и заняться какой-то произвольной конфигурацией. Провайдеры хостинга — не интеграторы сторонних систем, поэтому решения мы, как и наши коллеги, стараемся делать максимально унифицированными.
В этом сценарии - несоизмеримо дешевле (почти наверняка бесплатно). А в целом сравнивать можно, если иметь чуть больше данных. Как правило, с serverless сервисами работает подход - если нагрузка плавающая и не очень хорошо прогнозируемая, то их использование часто будет дешевле.
Если нагрузка постоянная и хорошо прогнозируется, то экономическая целесообразность serverless считается заметно сложней, через TCO и потенциальную экономию в процессах разработки, а не в явном виде в инфраструктуре.
Спасибо за обратную связь! Про монтирование бакета - скоро будут апдейты, подключайтесь к трансляции нашего трека на https://scale.yandex.ru/
В случае менеджеров, можно работать много и постоянно быть в рабочем тонусе, просматривать почту, отвечать на задачи в джире, что-то придумывать, записывать куда-то идеи — это все будет называться, по крайней мере в моем мире, — работать.
При этом, конечно же, я более чем согласен с комментариями выше: при выполнении задач требующих максимальной концентрации (например, будучи разработчиком) — невозможно выполнять их с одинаковым и приемлемым уровнем качества в течении продолжительного времени.
Ты не делаешь подряд сформулированные задачи, где тебе нужен фокус. Ты постоянно держишь в голове всю картинку в целиком, выделяя на те же самые конкретные задачи строго определенное время максимальной концентрации.
Является ли это временем потраченным на работу? Да. Является ли это следствием неэффективности? Нет. Это вообще не про то.
GitLab нужно как минимум 2 Гб памяти, если мне не изменяет память. Gogs неплохо работает на самых простых конфигурациях с 512 памяти в Vscale. Правда стресс-теста с огромным кол-вом реп я не делал.
Ну и плюс держать репозиторий локально не все готовы. Gogs на текущий момент — хорошая, производительная и легкая альтернатива ресурсоемким GitLab, RHC, Stash и прочим self-hosted решениям.
Может вполне использоваться, как приватный репозиторий. Ну а в будущем, думаю, у них появится и кодревью (pre-merge) и сниппеты. Все это обсуждается.
https://about.gitlab.com/2015/08/05/6-reasons-why-pre-is-better-than-post-production-code-review/
Есть ряд нюансов:
— Все пакеты нужно где то хранить и обновлять
— Чем больше пакетов ставить — тем больше ставится скалет
— Не все кейсы нужны кому то, кроме пары человек
Все это накладывает ограничения. В том числе, например, образ с WordPress или образ с GitLab — ставится не на все тарифные планы. Тут тоже имеет место прежде всего возможность гарантированно стабильной работы на выбраном конфиге для большинства пользователей. Понятно, что немного подтюнив сервер (установить ngnix для статики, отказаться от apache, подключить swap раздел) — можно установить и на меньшие конфигурации, но все это требует тонкой настройки, которая индивидуальна в большинстве своем.
Но это и не сильно важно. В любом случае, спасибо за отзыв.
Но за отзыв — спасибо, о проблеме знаем и работаем над этим ( и в принципе над публичным сайтом ).
Поэтому, конечно, порой действительно все равно нужно пойти на сервер по ssh и заняться какой-то произвольной конфигурацией. Провайдеры хостинга — не интеграторы сторонних систем, поэтому решения мы, как и наши коллеги, стараемся делать максимально унифицированными.