Це дещо дивно, що провайдер заявляє ліміти, бо якщо OLT-комутатор знаходиться безпосередньо в точці обміну трафіком на площадці провайдера (а саме так запевняв мій провайдер) то від генератора він може живитись умовно безкінечно довго, решта елементів на лінії, як вже згадувалось, пасивні і живлення не потребують аж до клієнтського обладнання

Нетфлікс, спотіфай, амазон, глово, уклон, десятки дрібних інтернет-магазинів — ніхто не реджектить. Для платіжної системи — це звичайний мастеркард з номером, CVV, датою і т.п. без привязки до пластика

А хтось ще досі використовує для платежів онлайн фізичну картку замість віртуальної з можливістю її закрити і перевидати нову безкоштовно?

Тільки от далеко не всі відкрито кажуть, що вакансія передбачає он-кол, а дехто відверто бреше, що «в нас один дзвінок в місяць» а по факту через ніч прокидаєшся. Тому що наявність 24×7 он-кол в вакансії робить її непривабливою відносно інших через очевидну шкоду для менталки і здоровя загалом.

Розподіл меж відповідальності та овнершіпу між командами/підрозділами, визначення TCO конкретних компонентів системи, автономність команд в прийнятті рішень і багато чого іншого.

Не пару грн в місяць. І не для всього підходить, так як код повинен бути адаптований під лямбду

1. Лямбда не пропонує жодної персистентності для даних (привіт RDS, бо дуже сумніваюсь, що автор пет-проект розробляв з розрахунком на DynamoDB з on-demand планом)
2. Лямбда не пропонує опцій для static assets (привіт S3 + CloudFront)
3. Лямбда не працюватиме без точки виходу в світ (привіт ApiGateway)

Тут ми вже наближаємся до 100USD в місяць, далі нема сенсу продовжувати

Треба обрати між дешевше і простіше, це взаємовиключні речі, тому треба відштовхуватись від фактичних потреб проекту. Дешевше — VPS на будь-якому хостинг-провайдері. Простіше — AWS AppRunner чи альтернативи від інших клаудів

Це який сетап? На burstable-інстансах?

Тому що 2 reserved instances найдешевший варіант це db.t3.small: 2 * 750 * 0.049 = 74$.

Так, на t-інстансах. Від 200 баксів буде сетап на c-інстансах з Multi-AZ, якщо потрібіно передбачуваний перфоменс. Навіть при цій ціні — це в рази дешевше, чим operations витрати на аналогічний сетап на он-премі.

Ось в мене maintenance вікно вночі, а перезавантажувались посеред дня. Та і що можна кожен тиждень оновлювати?

Регулярне спонтанне перезавантаження on-demand — це не нормально і потрібно розбиратись з сапортом. Щодо апдейтів — то секюріті патчі ОС виходять раз в кілька днів, тому щотижневий апдейт — це ще великий інтервал. Звісно ж інструмент треба підбирати під задачу і бюджет, якщо від продукту не очікується відповідність секуріті-практикам і не вимагається ніяких сертифікацій чи нема вимог до аптайму — то для сайту замовленя суші з 100 замовлень в день, віртуалка може бути не таким вже і поганим варіантом за свої гроші (до першого серйозного факапу чи інцеденту, звісно ж)

До речі, «економимо» та RDS — це слова антоніми. AWS бере 10Х націнки за сервери.

Клауди не беруть націнку за сервери. Клауди беруть націнку за сервіс обслуговування програмного забезпечення, що виконується на серверах і надається кінцевому споживачу як сервіс, з мінімальним порогом входу без потреби будь-яких додаткових опс-витрат.

Якщо економити, то можна запустити СУБД на VPS, наприклад, Hetzner, та отримати чесні
2 CPU, 4 GB RAB, 40 GB за $ 4.59 на місяць.

Якщо в Вашому проекті можливо замінити клауд на хостер віртуалок — це означає, що Ви використовуєте клауди не правильно або вам вони не потрібні взагалі. Але, навіть у випадку, якщо Ваша БД запущена десь на системнику за туалетом — вам потрібен сісопс в штаті, щоб ця БД була хоча б якось придатна до production-використання (патч-менеджмент системи і БД, бекапи, відновлення після катастроф, аудит безпеки і т.п.), і тому ціна менше сотні баксів за Multi-AZ сетап виглядає явно більш виграшним варіантом, враховуючи, що це під силу рандомному мідл-бекенду наклацати в вебконсолі кластер БД з бекапами, автоапдейтом і т.п.

Ще хотів додати, що SLA в RDS single AZ deployment 99,5%, тобто десь годину на тиждень сервер може не працювати і це буде нормально с точки зору зобовʼязань AWS перед вами. В нас таке теж було, що іноді раз на тиждень AWS десь на 10 хвилин наш сервер вимикає та перезавантажує його.

Раз в тиждень БД може перегружатись через ввімкнений maintenance window в нічні години і установку апдейтів. Навіть single-az нештатний даунтайм це виняток.

Це абсолютно різні речі. Мілтек, мобайл, політика і т.п. це «білі» домени. Контент 18+ під питанням і залежить від місцевих законів. А робота на гемблу чи інший скам в резюме — прямо говорить про морально-етичні погляди кандидата. Тому, вестерни не спішать наймати таких людей (особливо на проекти, де є доступ до фінансових чи клієнтських даних) як потенційно ненадійних

Це факт. Власноруч підписував контракти чи НДА (США і ЮК), де було вказано, що я підтверджую, що не мав жодного відношення до гемблінгу.

ESP не має енегроефективних SoC опцій, їх МК максимально прожорливі і з sleep/standby режимами катастрофа, годяться хіба що для живлення від мережі чи великих батарей, і то виключно в випадку, коли потрібен повноцінний TCP/IP стек і передача реально великого обєму даних. А якийсь дрібний ІоТ девайс, що десь приліплений далеко від розетки і працює на одній AAA батарейці, чи від сонця + суперконденсатор, з якого час від часу треба зібрати пару байт даних, не зробиш. А з STM32 +LoRa/BLE/NRF — зробиш.

Навпаки, розбиратись в чомусь більш технологічному, чим те, чим займаєшся в даний момент. Бо саме завдяки тому, що людині зараз не потрібно тикати палкою в землю, щоб виростити їжу, в наш час літаки літають, інформація передається за мілісекунди на інший бік глобуса, а смертність від пневмонії не 25%, як було ще 100 років тому.

Джун — не знає як треба робити
Мідл — знає, як треба робити
Сенйор — знає, як НЕ треба робити

А оці «незрозумілі мерехтливі білі кулі» виглядають точно так же, як і літак (чи ракета, чи дрон), що рухається на грані подолання звукового барєру

Якщо ви не економите — ви рано чи пізно в будь-якому випадку вилетите в трубу, не важливо, наскільки дорогими (чи дешевими) інструментами ви користуєтеся. DO і Hetner на цьому ринку це доганяючі — вони ніколи не стануть амазоном, ажуром чи гклаудом

Клауд — це не чорна скриня з магією. Щоб ми могли в кілька кліків (чи кілька рядків IaC коду) запустити віртуалку з лоадбалансером — під капотом за цим всім дивляться десятки тисяч адмінів/опсів/інфра інженерів. Клауди лише в певній мірі перетасували розподіл спеціалістів. Але досі по ДЦ ходить інженер і руками міняє диски, що посипались, в серверних стійках.

Заради цікавості, як ви запобігаєте усіляким email spoofing, spear phishing, BEC, email bombing, та іншим атакам?

Практично всі клієнти, з ким працював останнім часом, використовують email as a service, тому це клопіт їх інженерів, максимум це додавав SPF/TXT записи, що third-party сервіс генерує. AWS SES, пригадую, взагалі DKIM/SPF все автоматично додав в Route53.

Це для якої спеціалізації він став базовий? За останні років 10 тільки один раз доводилось на цьому акцентувати увагу (ще тоді коли DMARC був чернеткою), і жодного разу не бачив в вимогах до вакансії, хоча постійно займаюсь інфраструктурою. В добу всяких Mailchimp і SES це дуже нішевий протокол.

Як на мене, цілком логічно, чому нема кандидатів. Не знайти такого спеціаліста, який вчив всякі DMARC, DKIM, SPF, PTR і т.п. тільки заразди цих технологій, тому що це повністю useless само по собі. Якщо хтось до цього і добрався, то в нього в резюме вже 100% є і лінукси, і постфікси, і віртуалізація і т.п. а ще він всякі тунелі на цісках конфігурити вміє, а це вже повноцінний Infrastructure/SRE engineer, який, що логічно, не погодиться на манкіджоб без явних перспектив росту.