Обидно конечно, но тут чуда же не произошло - контора получает доход в рублях и при изменениях внешних условий она очевидно будет как-то выкручиваться, причем не за счет же владельцев это делать.
Напоролись на такую проблему у себя - используем СМС авторизацию, в мобильных клиентах и разного рода телевизорах. Атакующие отправляют по 1 смс, с разных адресов и на разные номера. В результате бан лист разрастается, но проблема никуда не уходит. Быстро сменить адреса вызовов нельзя - отломаются клиенты (которых целый зоопарк), поэтому приходится все время подкручивать лимиты, и потихоньку переходить на новые апи, а старые банить.
Как же напрягает наличие кучи протоколов и разных хабов, приложений и тд. Климат-контроль в одном приложении, лампочки в другом, бытовая техника в третьем. А еще завязка на интернет — сдохла сеть и вот уже умная колонка стала тупой и не может включить свет в коридоре. За технологиями умного дома будущее, но то что есть сейчас это ранние попытки разобраться как делать правильно, и ходить по граблям вместе с производителями уже честно надоедает.
Да, синхронность галеры может доставить проблем там где нужна скорость. Но вроде как у вас сервис как раз таки требующий надежности хранения данных. Кроме того по идее можно иметь группу нод галеры + слейвы, то есть тормоза будут только на запись. Ну и получается что если сейчас возникнет проблема с ДЦ то сервис склеивает лапки, так?
да, черт возьми! врядле объем мусора будет превышать объем доставленного заказа. Вообще все магазины доставки продуктов было б хорошо приучить забирать тот мусор который создается от их товаров (кучи пакетов, кучи пластиковой упаковки, стекло и тд).
это canary деплой, когда новый инстанс поднимается рядом, без убивания старого. По поводу проблем с выводом нод на обслуживание и большими кластерами — не сталкивался с такими жесткими глюками ( юзаем номад больше 2х лет). Общались с разработчиками по поводу этих багов?
ну сбор и анализ статистики нужен когда бизнес достигает определенных объемов. Так что ниша это достаточно важная и нужная. Я работал с КХ на бою и она достаточно хорошо себя ведет (в ней было несколько терабайт данных)
serverless актуален для различных облачных сред, где персистентное хранилище предоставляется как служба (тот же amazon dynamodb). Так что вполне можно разрабатывать только serverless код, а всю боль со stateless отдать на откуп провайдера. Я не думаю что многие разрабатывают по настоящему stateful приложения, которым очень нужен доступ к диску для корректной работы, обычно все ходят за данными во внешние сервисы (та же SQL/noSQL/kv база данных).
Скорее всего это был перевод с serverless. Такие сервисы как например Amazon Lambda. В этом случае приложение является как бы функцией которая запускается по требованию.
И что значит «без жестко закрепленного мастера»
да, raft. Все сервера и мастера и клиенты ( ну это потому что кластер небольшой)
В Swarm например тоже нет захардкоженного мастера, есть набор менеджеров, какждый из которых может взять на себя роль лидера на некоторый период.
про swarm тоже в курсе, на тот момент он был еще сырой. я думаю поковыряюсь еще со swarm, так как он все таки встроенный в docker. Однако с nomad удобно то, что он поддерживает достаточно много функций связанных с оркестрацией, кроме того он позволяет управлять не только контейнерами но и вообще любыми исполняемыми типами, включая запуск обычных бинарников или виртуальных машин (kvm/qemu).
Использую nomad+consul на нескольких проектах. Очень удобно когда небольшая инсталляция и не хочется тащить кучу компонентов в систему. У этой связки все сервера равноправные и без жестко закрепленного мастера. Stateful сервисы тоже управляются через nomad.
На k8s смотрю и изучаю, но есть желание дождаться когда он станет более стабильным и там закончится этап бесконечного накидывания фич и пойдет чисто багфиксинг.
Сам код никому не нужен, нужно решение задач бизнеса. Если разработчик этого не хочет признавать, то наверное ему место только в опенсорс/собственных проектах. Хороший код нужен бизнесу только тогда, когда его написание и поддержка обходится дешевле говнокода, а это наступает далеко не сразу.
А есть например дока по «правильному» внедрению заббикса например для kubernetes? Я так понимаю что сейчас все равно нужны какие то танцы с бубнами чтобы добавлять хосты в заббикс, из коробки тот же kubernetes делать ничего не будет.
alexvl а сейчас есть функционал для мониторинга динамически меняющихся окружений? приложений выполняемых в системах оркестрации типа kubernetes/mesos/nomad? хотелось бы функционал «виртуальных» узлов для высокоуровневых сервисов а еще легкое динамическое создание и удаление инстансов.
Вода в кастрюле закипала медленно, поэтому лягушка не сразу поняла что происходит, а когда поняла...было уже поздно
Обидно конечно, но тут чуда же не произошло - контора получает доход в рублях и при изменениях внешних условий она очевидно будет как-то выкручиваться, причем не за счет же владельцев это делать.
А как вы закрывали риск, что эти обученные сотрудники ощутив свои силы уйдут в рынок на конские зарплаты?
Напоролись на такую проблему у себя - используем СМС авторизацию, в мобильных клиентах и разного рода телевизорах. Атакующие отправляют по 1 смс, с разных адресов и на разные номера. В результате бан лист разрастается, но проблема никуда не уходит. Быстро сменить адреса вызовов нельзя - отломаются клиенты (которых целый зоопарк), поэтому приходится все время подкручивать лимиты, и потихоньку переходить на новые апи, а старые банить.
И что значит «без жестко закрепленного мастера»
да, raft. Все сервера и мастера и клиенты ( ну это потому что кластер небольшой)
В Swarm например тоже нет захардкоженного мастера, есть набор менеджеров, какждый из которых может взять на себя роль лидера на некоторый период.
про swarm тоже в курсе, на тот момент он был еще сырой. я думаю поковыряюсь еще со swarm, так как он все таки встроенный в docker. Однако с nomad удобно то, что он поддерживает достаточно много функций связанных с оркестрацией, кроме того он позволяет управлять не только контейнерами но и вообще любыми исполняемыми типами, включая запуск обычных бинарников или виртуальных машин (kvm/qemu).
На k8s смотрю и изучаю, но есть желание дождаться когда он станет более стабильным и там закончится этап бесконечного накидывания фич и пойдет чисто багфиксинг.