Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, тут только опция контроллировать потребление сообщений на уровне consumer. Но проблему это не решает по тому что если база выдерживает нагрузки ниже чем скорость поступления новых сообщений то лопнет уже очередь, а не база. Так что сама идея не имеет смысла
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, это входит в концепции serverless в которой делается решение. Если нет даже такого базового понимания то вы куда вообще полезли? Решение надо считать со всех сторон и иметь достаточную компетенцию.
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, а как давать ответ на вопрос, который сам себе противоречит "мы хотим не положить базу, но мы не хотим потерять приходящие метрики". Узкое горлышко в данном вопросе - база и все что не является ее масштабированием в данном вопросе не имеет никакого значения, включая финансовую составляюшщую
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, в тот момент когда было произнесено название AWS Lambda - вы получаете полую жесткую зависимость от вендора. Serverless невозможен к легковесному переносу какие бы фреймворки в виде https://www.serverless.com не существовали по причине того что Serverless это одновременно огромная группа сервисов и особенностей инфраструктуры на которой оно работает.
Что до бюджета то необходимо запускать тесты и рассчитывать стоимость решения чтобы не обанкротиться. Ну или хотябы в первом приближении посчитать на калькуляторе, но судя из уровня понимания AWS на данный момент - это непосильная для вас задача. Даже при моем опыте с AWS это может занимать часы и множество перепроверок рассчетов.
Нагрузку же всегда можно просчитать.
Если же вы хотите контроля масштабирования то определитесь зачем оно вам. Если для того чтобы сократить расходы то вы сразу попадете в ловушку по тому что Serverless предполагает что 99.(9)% ресурсов вы не имеете возможности контролировать. В этом весь смысл данной архитектуры. Но за это вы получаете бонус в отсутствии почти полной потребности в расходах в поддержку и безопасность с мониторингом. Оно закладывается в стоимость. Ну и сокращает Time To Market.
Полный контроль над масштабированием требует сегодня навыком контейнеризации, тяжелые обвесы мониторинга и высокую сеньорность команды, что очень сильно влияет на стартовые расходы на проект и отодвигает дату его релиза.
Добро пожаловать в реальный мир без магии в розовых единорогов
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, DynamoDB предоставит практически безлимитную пропускную способность в зависимости от настройки, конечно. Поэтому все эти пляски с бубном на счет "не перегрузить" базу можно будет просто спустить в унитаз. Кроме того, DynamoDB. находится в экосистеме AWS и интегрирован с огромным числом других инструментов. Это типовое решение в AWS Serverless подходе. И других опций у вас просто нет на самом деле.
ettaluni, все там есть. Если вы чего-то не знаете это не значит что его там нет. Xdebug никто не отменял. Браузер вообще штука не обязательная, особенно учитывая что не все приложения на php это веб-сайты) учим матчасть и не стесняемся хотябы основы работы с языком изучить
ettaluni, если phpstorm «мешает» писать код то стоит задуматься не о качестве редактора, а о том что вы делаете не так. Это инструмент #1 сегодня для разработки на php и с него уходят только 2 категории людей:
- переходящие в другой стек
- те, кто любит страдать, а не разрабатывать
ettaluni, клиент понятное дело что свой. Другое дело что перезапуск дело не нормальное. Стоит разобраться как восстанавливается там соединение, а не искать обходные пути.
somefhjs, нет. Ну, разве что если это не рабочая станция или корпоративный репозиторий. Согласно этой логике, самозанятой фрилансер, работающий по выходным - тоже создаёт собственность компании. Что является не верным.
Типовой трудовой договор включает в себя условия, описывающие:
- время, которое отводится на работу (полный рабочий день означает 8 рабочих часов в день, 40 часов в неделю)
- должность
- набор должностных инструкций
Пункт про права на произведённое ПО накладывается только в рамках действия трудового договора. Даже овертаймы считаются по ТК только в случае если они были заранее согласованы с работодателем.
Все время, проведенное за рамками работы - только вообще и тратить его можно на что угодно (даже на работу, есть такие люди)
История с Nginx в частности имеет проблемы с той стороны что этот продукт разрабатывался изначально для внутренних целей компании
somefhjs, любые разработки в не рабочее время, не относящееся к работодателю и так относится к категории авторских прав, являющихся неотъемлимыми. Вот если софт пишется для работодателя или используется им то тогда встают вопросы
balex777, микросервисы это вообще не про язык программирования и фреймворки. Если их выкинуть из вопроса - вообще ничего не изменится. Надо читать именно про микросервисы, зоны ответственности и контракты
Данила, советую хоть пару роликов на ютубе глянуть. Один виртуальный сервер может обрабатывать хоть сотни тысяч пользователей одновременно. Все зависит и от качества кода и выделенных ресурсов. А виртуальных машин на железке тоже может быть не одна, а десятки и более - зависит от мощности железа и контроля ресурсов. Посчитать сколько пользователей может обслуживать одна железка без нагрузочного тестирования в принципе задача сложнее чем путешествия во времени
Данила, там далеко не все, кроме того там точно нельзя учесть облака по тому что в них эти цифры меняются ежедневно. Кроме того есть еще и амортизация и утилизация. В общем, все цифры +- все-равно вымышленные
