Доброго дня, ріквест був від бізнесу якраз щоб були опрацьовані всі ріквести, цього зображення в статті немає (саме цієї статистики) вона тут є лише частково, але еррор рейт був 0, тобто всі ріквести отримали успішний респонс, найбільший тайм період що я дивився це було 3 тижні і проблем не було з цим.

Доброго дня. Основний посил статті трохи про інше, однак відповідаючи на ваше питання звісно розглядались інші варіанти і відомо було про інші варінати (як мінімум проект до цього був на спрінгу) конкретно під наші вимоги кваркус був кращим варіантом по масштабуванню і колд старту. Більш детальні порівнянні є в т.ч від AWS так і на іших популярних ресурсах в англомовному комьюніті.

Доброго дня, дякую за коментар. Частково я з Вами погоджуюсь, що стосується комьюніті в Спрінга воно однозначно більше, так в Кваркуса можуть бути певні не критичні (при наймні для мене) незручності. В нашому випадку був супер критичний колд старт на випадок потреби в масштабуванні лямди під час пікового навантаження і як не крути в Кваркуса він кращий + середовище яке більш націлене на обмеженому використанні рефлексії (бібліотеки) буде давати кращий результат. Але знову ж таки це наш випадко і наші вимоги суть статті полягає якраз в тому, щоб використовувати можливості під вимоги бізнесу а не просто робити по шаблону. В випадку якщо вимоги були б іншими Спрінг був би кращим варіантом через те що більше людей з ним знайомі хоч і вимагав би більшого від їх навчок по дизайну коду.

Доброго дня, коротка відповідь ні, не збереглось. Стаття писалась не зразу після рефакторингу і нажаль не всі метрики зберіг.

Доброго дня, чудовий результат, стаття саме про це, щоб обирати по потребі а не просто бо так звикли.

Доброго дня, по-перше мушу подякувати за Ваш обширний коментар і Ваш час. По-друге, що до самого коментаря: повністю згоден з першою частиною це класичний простий проект без складного CPU обчислення, щодо другої частини як я писав в іншому коментарі це ж не просто х сервісів і все, це проект де є різна кількість енваєрментів і не один маркет що і генерувало кост.

Доброго дня, рахунок виглядав би всеодно на користь лямди конкретно в цьому. В лямдах ви платите за час використання а не 24.7 + не забувайте за free tier, в цьому проекті не було складних CPU операцій тому і довгого дюрейшена виконання. Але суть статті трохи в іншому, стаття не про те що ось це хороше а це погане, стаття про те що при розробці і дизайну інфраструктури треба зважати на потреби бізнесу, а не просто робити шаблонно бо так звикли.

Доброго дня. Насправді досить просто. Використання інфри не по потребі проекту, а до якої звикли (однак зазначу що в цьому випадку коли проект починали робити, стабільного рішення під лямди не було) помножити на Х енваєрментів (хоч вони і оптимізовувались, тобто не було тих самих ресурсів що на проді для дева наприклад) помножити на Х маркетів + інші пріоритети бізнесу.

Щиро дякую!

Доброго дня, ні база залишилась без змін, хоча спочатку були думки спробувати з використанням серверлес бази даних, але при більш детальних тестах вона не дала великого результату але по ціні була дорожчою.

Доброго дня. Нажаль прям точної відповіді з % надати не зможу, що повпливало і в якому співвідношенні, в основному тощо збір подібної метрики зайняв би дуже багато часу і прям повністю її зібрати неможливо було (поясню трохи пізніше). Стосовно припущень, CPU маловірогідно конфігурація лямд надавала там далеко не супер топові варіанти CPU (просто нагадаю що прям обрати CPU Ви не можете, CPU буде залежати від того скільки оперативної пам’яті ви оберете. Якщо говорити за те що використовувалось в нас а це лямди 128 мб і 512 мб то альтернативої їм є t2.nano або t3.nano і t3.micro або t2.micro EC2. ІО точно став швидшим і також сильно вплинув Кваркус з нативкою. Тепер до найбільш цікавого чому зібрати точну метрику було неможливо, причиною цього був баг у AWS, а саме холостий простой запиту коли ріквесту пішов але до лямди не дійшов і знаходиться в простої або подібні випадки які були помітні на X-Ray. Це не займало супер багато часу, тому це не було чимось критичним для бізнесу, але подіну метрику 100% б заафектило. Нажаль більш детально розповісти не можу.

Доброго дня, Community Edition — вона безкоштовна.

Доброго дня, тільки нативний варіант.

Доброго дня, стаття якраз про те що потрібно розглядати кожен випадок окремо і кожен проект окремо. Конкретно в цьому проекті, як не крути навіть якщо лоад буде стрибати до набагато більших значень найвигіднішим варіантом буде лямди. Якщо ви бачите що буде велике стабільне навантаження 24.7 з великим використанням CPU або часом виконання то лямда це не Ваш варіант, але якщо ви розумієте що в вас величезний час простою то немає сенсу тягнути туди щось дороге по інфраструктурі (також будемо пам’ятати про free tier). Нажаль тотальна більшість не зважає на це і генерує величезні кости за інфру там де це не потрібно, просто тому що або працювали тільки з таким, або вже звикли до чогось одного від чого в результаті буде страждати бізнес.