Ні не скажуть. Якщо маєш Computer sience/engineering диплом навіть українського провінційного вузу — для багатьох кастомерів це сильно збільшує твої шанси відносно тих, хто його не має.

Якщо працювати на українську галеру чи клієнта то так, але якщо піти на інтерв’ю до кастомера з старої Європи чи США, то 95% з них запитають про освіту.

Якщо вимоги до reliability близькі до нуля, тоді і клауд-рішень не треба, за ціною нормальної шавухи можна на місяць взяти віртуалку на хейнері.

Не погоджусь. Якщо порівнювати з ECS, Kubernetes (у вигляді EKS) сам по собі мало придатний для прод-вокрклоаду, і потребує як мінімум:
1. Моніторинг ресурсів кластера і система алертінгу
2. Log-агрегатор типу ELK/EFK
3. Ingress (по-дефолту ніби і є ALB Ingress, але потребує доопрацювання напилком)
4. Маппінг IAM to k8s RBAC.
5. Вже згаданий cert-manager

Саме тому кілька сусідніх команд проекту хостяь сервіси в ECS, який ready to go (де все це або уже реалізовано cloud-native штуками типу CloudWatch, або реалізовується в кілька рядків терраформу через додаткові нативні сервіси), так і кажуть, що нема експертизи в k8s.

Серйозно? 47 баксів коштуватиме для клієнта приблизно одна година роботи одного сенйор-інженера, тому двозначні цифри в monthly bill за хостінг це взагалі останній аргумент для кастомера.

Це хибне судження від спеціаліста, що давно подолав поріг входження в кубер (за собою таке ж помітив, що хочеться кубер зі всіма його плюшками там, де його точно не треба), обєктивно для простих проектів на 3-5 мікросервісів managed-рантайм контейнеризації (типу ECS + Fargate) більш придатне і дешевше в плані operations рішення, чи навіть VM-ки + аутоскейлінг.

А в чому, власне, проблема? Бухгалтери, лікарі і вчителі масово теж працюють як ФОПи (не на державні установи, звісно ж)

Згоден, сенйор — це не той, хто знає, як треба (таких багато), а той, хто знає як НЕ треба, хто має багаж факапів і зроблених з них висновків.

маєте на увазі нюанси через лінуксовий енв?

В основному, танці з бубном навколо ліб, які мають системні залежності (.so файли)

про той pay-as-you-go думав, якщо хайлоад, то там і хайгешефт.

Хайлоад == хайгешефт хіба B2B сегменті, де стейкхолдер продає своєму клієнту одиничні дорогі транзакції. В B2C ж навпаки, дуже багато дешевих транзакцій (конверсія інтернет-магазинів чи подібних ресурсів в приклад), тому інфраструктура може влетіти в копієчку. А тут вже виграє, наприклад, EKS, який коштує практично в ціну EC2 (а за EC2 дешевшого compute-ресурсу нема), але дорогий в обслуговуванні (на відміну від лямбди). Тому, калькуляцію треба робити враховуючи особливості конкретного продукту.

Lambda — для малих проектів. Нюанси з використанням сторонніх бібліотек. Warm-up довго, час респонсу високий. Vendor-locked. Деплоїться швидко і легко, не потребує великої кількості додаткових компонентів та експертизи (Api Gateway + ALB і погнали). Дешево в малому масштабі, дорого при хайлоаді.

Docker — гнучко, універсально, швикдо. Широкий вибір способів запуску (VM з будь-яким дистрибутивом, Kubernetes, ECS/Fargate, ACA і т.п.). Vendor agnostic. Практично завжди потребує додаткових налаштувань середовища виконання (навіть у випадку managed services). Обійдеться дорого при невеликому ворклоаді. Відносно дешево в хайлоаді.

Аналогічно. З моїх спостережень 40% прийшли з девелопмента (Software engineer, на якого скидали задачі по розгортанню інфраструктури і автоматизації SDLC, а з ростом проекту вони почали цим займатись фул-тайм), решта з Infrastructure engineering, які навчились в білди, автоматизацію і т.п.

Девопс інженера не існує

Щось схоже на погляди плоскоземельщиків. Скрам — це теж процес. Як і Quality Assurance. Існування скрам-мастерів і QA-інженерів теж заперечуєте?

Саме тому я і відокремлюю в своїх твердженнях DevOps і DevOps engineer. Як і QA — це теж про підхід, а QA engineer — це фахівець, який цим займається.

Щоб не мати хибних очікувань, треба знати про Devops Engineer те, що він повинен займатись, як це не дивно, DevOps. Не налаштовувати чи масштабувати сервери, сервіси і мережі (привіт Infrastructure engineer), не будувати високодоступні системи і не займаєтись їх підтримкою (привіт, SRE), не роздає доступи і не допомагає з налаштуваннями (привіт, System Administrator). DevOps — це про пайплайни, білди, деплої, тести, оточення і SDLC. DevOps інженер — це частина команди розробки і працює в відповідному скоупі задач, але аж ніяк не окрема команда (як у Infrastructure чи Site reliability engineers).

В ентерпрайзі прийнято мати свій базовий імідж, який періодично перебудовується з публічного іміджа і проходить аудит безпеки, а ось поверх цього іміджа уже збирати контейнер з аппкою (вказувати для апп-докерфайла FROM myrepo.com/ubuntu-base:latest, а в разі потреби відкату можна використати старіший тег, типу myrepo.com/ubuntu-base:1.2.3), таким чином завжди можна перезібрати конкретну апку з будь-яким базовим іміджем.

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

Мені в укртелекомі прямо відповіли: на вузлах на моїй лінії резервного живлення нема, і якщо пропаде світло — впаде нет.

Можу впевнено сказати, що в DevOps практиці досвід, як НЕ треба робити, більш цінний, ніж знання як треба (звісно, якщо з кожного факапу зроблені висновки і проаналізовано root causes), а як треба нам розкажуть доки, трейнінги і т.п. але, як завжди, все буде присипано маркетинговою мішурою і неозвучені нюанси. Тому треба дозволити mentee пройтись по граблях і набити гулі — це невідємний крок на шляху становлення спеціаліста.

Зі збільшенням рівня доходів варто уникати пастки інфляції способу життя, а це можливе тільки з самодисципліною

Чому ж? В use-cases здорової людини Elasicsearch дуже потужний інструмент.