Все верно! Условно говоря, если выразить стоимость приложения в понятных единицах, вроде вычислительных ресурсов, хранения данных, количества запросов и усредненном времени их исполнения - мы можем получить достаточно точное сравнение стоимости размещения приложения в зависимости от выбора инструмента.
Чуть сложней, когда мы пытаемся оценить именно стоимость владения, в которую входят не только потраченные на размещение приложения ресурсы, но и time-to-market, стоимость эксплуатации и прочее. Здесь так или иначе придется использовать какую-то из вариаций TCO модели, которую в каждой компании будут считать несколько по-разному.
В этом сценарии - несоизмеримо дешевле (почти наверняка бесплатно). А в целом сравнивать можно, если иметь чуть больше данных. Как правило, с 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 раздел) — можно установить и на меньшие конфигурации, но все это требует тонкой настройки, которая индивидуальна в большинстве своем.
Сейчас есть возможность увидеть все фичи после основной регистрации (активация по ссылке из почты). В целом — это достаточно быстро и удобно. Если все понравится — активируете учетную запись полностью (смс и привязка карты).
Но за отзыв — спасибо, о проблеме знаем и работаем над этим ( и в принципе над публичным сайтом ).
Все верно! Условно говоря, если выразить стоимость приложения в понятных единицах, вроде вычислительных ресурсов, хранения данных, количества запросов и усредненном времени их исполнения - мы можем получить достаточно точное сравнение стоимости размещения приложения в зависимости от выбора инструмента.
Чуть сложней, когда мы пытаемся оценить именно стоимость владения, в которую входят не только потраченные на размещение приложения ресурсы, но и time-to-market, стоимость эксплуатации и прочее. Здесь так или иначе придется использовать какую-то из вариаций TCO модели, которую в каждой компании будут считать несколько по-разному.
В этом сценарии - несоизмеримо дешевле (почти наверняка бесплатно). А в целом сравнивать можно, если иметь чуть больше данных. Как правило, с 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 раздел) — можно установить и на меньшие конфигурации, но все это требует тонкой настройки, которая индивидуальна в большинстве своем.
Но это и не сильно важно. В любом случае, спасибо за отзыв.
Но за отзыв — спасибо, о проблеме знаем и работаем над этим ( и в принципе над публичным сайтом ).