Если кто-то отказал, уже за рамками выравнивания команда продукта привлекает руководителя и занимается переприоритизацией
Интересует вот такой момент. На выравнивании вам отказали в 2 проектах. Другой команде в одном проекте ну и так далее. В итоге у вас освободилось капасити и у кого-то тоже. Митинг выравнивания закончился. Счастливые команды у кого все ок побежали делать работу а оставшиеся будут пытаться придумать как им быть и какие проекты они могут сделать без чужой помощи? Или какой флоу в таком случае?
Да, в целом, почти любая тема имеет какой-то теоретический базис под капотом. Но лично мне всегда интересно изучать что-либо на практических примерах. И желательно узнавать это от людей, работающих в моей сфере(так как есть все-таки специфика), а не в государственных организациях, банках. Много книг написаны в 60-е - 80-е на примерах Американских компаний и их уже тяжеловато воспринимать.
Все естественно зависит от конкретного случая, но, в первую очередь, бизнес хочет делать функционал для клиента, и лучше, если быстро. Поэтому разработчики в таких случаях становятся T-shape, чтобы не расширять штат еще больше. То есть делают работу и разработчика и девОпса, и куа. И в этом случае, какими-то вещами будут пренебрегать.
Есть конечно и примеры полностью кроссфункциональных команд в стартапах, где сразу нанимают исходя из потребности X dev + Y qa + devOps +дизайнер + ПО. Но это обычно дороже, особенно в небольших масштабах.
Понял, не про тот рост подумал. В случае штата решает бизнес, если продукт узкоспециализированный и не требует инновации каждый день добавлять - возможно ок. Но что если это типа Амазона? Они тоже только книжками торговали.. а сейчас уже только сокращают десятками тысяч.
Типа сидеть за N сумму на легаси проекте и плевать в потолок? Я пока еще не слишком стар для этого д..а)) Шутка если что. Никого не осуждаю - не для всех работа - хобби и не каждая работа должна быть хобби.
Я для себя открыл цикл идеального развития скилов. Сначала вписываешься во что-то неимоверно интересное и сложное, доводишь до ума, набираешься экспертизы, а потом немного выдыхаешь. И так по кругу. Без выдоха - выгораешь, без сложностей деградируешь.
Вроде бы коротко и по делу, но вот чтение писем с помощью Spring/Spring Boot не освещено. Как раз по этой тематике очень мало информации, а существующая по Spring Integration выглядит немного странно с настройкой бинов через xml в 2020 году.
Было бы здорово и эту информацию осветить, если есть желание разобраться. Такое в принципе очень часто необходимо при автоматизированном тестировании отправки email и его содержимого.
Почти все верно, но по большей степени для асинхронных вызовов. Для них настраивается Retry pollicy (по дефолту 2 раза). Для синхронных запросов, как в моем случае, retry — это обязанность API Gateway либо консьюмера Api Gateway. Можно сделать на стороне JS к примеру.
Насчет шедулеров, это прямо одно из основных направлений я бы сказал. CloudWatch может работать по принципу cron job и триггерить запуск лямбды. Также для лямбды доступно огромное количество триггеров, который могут даже существовать параллельно.
Насчет своей инфраструктуры для лямбд, мне кажется зависит от специализации. Если огромная компания имеет такую потребность то наверно стоит оценить такую возможность. Естественно тут все упирается в рабочие ресурсы и производительность. Возможно вы потратите больше на зп разработчикам, чем провайдеру. Ну и чтобы добиться того же перформанса что имеется у aws/google придется попотеть))
Спасибо за такие заметки. Прочитал, и действительно, когда начинал проект собирать не было ни Provisioned Concurrency ни VPC NAT для лямбды, успел только 8 джаву обновить до 11.
А так надо будет провести пару экспериментов с Provisioned Concurrency.
rsync Если коротко, то все зависит от типа теста. В юнитах мокаем обычными средствами языка Mockito/PowerMockito.
В интеграционных тестах — зависимости, такие как база / S3 / любой другой сервис чаще всего поднимаются независимо в Docker.
В e2e, если есть возможность, поднимается дополнительный стек и дублируются зависимые ресурсы.
А вот тесты на безопасность и производительность в большинстве случаев опускаются, если применение асинхронное и AWS роли и политики четко заданы во всем аккаунте.
Также, с точки зрения производительности хорошо бы не забыть проверить как объем оперативной памяти влияет на скорость обработки, тем самым на затраты.
На вашем месте я точно также бы не стал замарачиваться с переводом готовой инфраструктуры на лямбды, особенно если идет разговор о каком-либо REST API и уже имеющем k8s инфраструктуре.
Но вот создание ETL процессов либо clean-up джоб — как раз под силу AWS Lambda. И при некоторых вложениях в автоматизацию CI/CD для лямбд, можно получить крутое решение как для любого dev/test окружения, так и для процессов архивации данных в проде.
Интересует вот такой момент. На выравнивании вам отказали в 2 проектах. Другой команде в одном проекте ну и так далее. В итоге у вас освободилось капасити и у кого-то тоже. Митинг выравнивания закончился. Счастливые команды у кого все ок побежали делать работу а оставшиеся будут пытаться придумать как им быть и какие проекты они могут сделать без чужой помощи? Или какой флоу в таком случае?
Не знал если честно, кажется стоит ознакомиться) Вот, узнал что-то новое сразу из комментов на Хабре, уже не зря статью писал.
А про спиралевидную структуру как я и думал написали в 60-е
Да, в целом, почти любая тема имеет какой-то теоретический базис под капотом. Но лично мне всегда интересно изучать что-либо на практических примерах. И желательно узнавать это от людей, работающих в моей сфере(так как есть все-таки специфика), а не в государственных организациях, банках. Много книг написаны в 60-е - 80-е на примерах Американских компаний и их уже тяжеловато воспринимать.
Зато память теперь навека, и на внуков чашек хватит)) ну и иногда поностальгировать можно
Все естественно зависит от конкретного случая, но, в первую очередь, бизнес хочет делать функционал для клиента, и лучше, если быстро. Поэтому разработчики в таких случаях становятся T-shape, чтобы не расширять штат еще больше. То есть делают работу и разработчика и девОпса, и куа. И в этом случае, какими-то вещами будут пренебрегать.
Есть конечно и примеры полностью кроссфункциональных команд в стартапах, где сразу нанимают исходя из потребности X dev + Y qa + devOps +дизайнер + ПО. Но это обычно дороже, особенно в небольших масштабах.
Понял, не про тот рост подумал. В случае штата решает бизнес, если продукт узкоспециализированный и не требует инновации каждый день добавлять - возможно ок. Но что если это типа Амазона? Они тоже только книжками торговали.. а сейчас уже только сокращают десятками тысяч.
Типа сидеть за N сумму на легаси проекте и плевать в потолок? Я пока еще не слишком стар для этого д..а))
Шутка если что. Никого не осуждаю - не для всех работа - хобби и не каждая работа должна быть хобби.
Я для себя открыл цикл идеального развития скилов. Сначала вписываешься во что-то неимоверно интересное и сложное, доводишь до ума, набираешься экспертизы, а потом немного выдыхаешь. И так по кругу. Без выдоха - выгораешь, без сложностей деградируешь.
Было бы здорово и эту информацию осветить, если есть желание разобраться. Такое в принципе очень часто необходимо при автоматизированном тестировании отправки email и его содержимого.
Насчет своей инфраструктуры для лямбд, мне кажется зависит от специализации. Если огромная компания имеет такую потребность то наверно стоит оценить такую возможность. Естественно тут все упирается в рабочие ресурсы и производительность. Возможно вы потратите больше на зп разработчикам, чем провайдеру. Ну и чтобы добиться того же перформанса что имеется у aws/google придется попотеть))
А так надо будет провести пару экспериментов с Provisioned Concurrency.
В интеграционных тестах — зависимости, такие как база / S3 / любой другой сервис чаще всего поднимаются независимо в Docker.
В e2e, если есть возможность, поднимается дополнительный стек и дублируются зависимые ресурсы.
А вот тесты на безопасность и производительность в большинстве случаев опускаются, если применение асинхронное и AWS роли и политики четко заданы во всем аккаунте.
Также, с точки зрения производительности хорошо бы не забыть проверить как объем оперативной памяти влияет на скорость обработки, тем самым на затраты.
Но вот создание ETL процессов либо clean-up джоб — как раз под силу AWS Lambda. И при некоторых вложениях в автоматизацию CI/CD для лямбд, можно получить крутое решение как для любого dev/test окружения, так и для процессов архивации данных в проде.