Що саме AWS?
щоб почати працювати

До рівня початківця щоб почати експериментувати?

та і не тільки

Щоб індуітивно про це говорити і продавати рішення — сумніваюся

ну я багато років працюю з AWS, але я не готовий говорити про big data/data lake etc, бо я з цим не працюю — хоча колись і вивчав для себе, отже все дуже залежить від цілей і потреб першого проекту куди націлився. Такий як у мене шлях — не у мене одного, в моєму отоенні достатньо людей хто перейшов у ефемерний девопс з сісадмінства поставивши ціль і не витрачаючи багато часу ознайомившись з основними тулами почав рухатись.

ну таке з вашого боку, якщо чеплятись до кожного слова — то я і досі вивчаю Амазон, Кубернетес, Докер і т.д і це аж ніяк не 2 тижні, а багато років.... Вивчаючи AWS це базово пару днів за рахунок AWS Sysop Operator за умовою що людина розуміє базові речі для сісадміна — мережі, ДНС, мейлінг, протоколи, фаєрволінг тощо. Спеціально подивився на udemy курси Aws sysop -+ 27 годин відео = 3 дні навчання. Terraform + AWS 15 годин відео = 2 дні навчання, Ansible 8 годин відео = 1 день навчання.
Таким чином можна витягнути себе дуже швидко — було б бажання. Я і без udemy перескочив на DevOps з мінімальними занннями AWS/Jenkins/Ansible/Python — просто маючи досвід керування фізичною інфрасткрутурою, деплоєм в ту інфру і коли готувався до сертифікації AWS — то мені було дуже нудно і дивно слухати про Route53 — що таке ДНС, як воно працює, по яких портах, протоколах, те саме про VPC з раутінгом.... тощо. Авжеж якщо бекграунду немає — то ані 2 тижні — ані місяць не вистачить, ані пів року...

AWS у мене зайняло десь місяць, разом з Terraform, доречі для Terraform написано пару книжок англійською які читаються одному диханні за пару вечорів (Terraform_ Up & Running — Yevgeniy Brikman, їх було 2 видання, зараз може більше) і маючи досвід того ж AWS, писати код под його інфру — не проблема. Ansible — це навіть не смішно, писати в декларативній формі навіть мій син у 13 років може, інше питання шаблонізатори, але це вже поглиблене як на мене і в ньому можно розібратись якщо знаєш що потрібно. Jenkins — що саме в ньому складного ? Фрістайл джобу зробити ? Якщо з логікою все ок — то немає нічого складного, ускладнене — це написання пайплайнів і groovy, але ж знову — це все ок, якщо з базовими знаннями немає проблем. Якось на співбесіді мене попросили зробити ТЗ — написати пайплайн складний, я погодився лише тому, що хотів прокачатись, ну за 4 дні розібрався, написав. Так що якщо з освітою, досвідом, логікою все ок — то і з навчанням проблем не буде.

не зрозумів вашу думку і що хотіли донести — вибачте.

типу допоки Perl був у використанні — я не зтикався з тим лайном, що переслідує Python вже не перший рік. Не пригадую у спільноті Perl обговорень про чорних, білих, здорових, хворих тощо...

Ну Python зі всією шайкою давно вже під питанням що вони роблять — розвиток python, чи ху...й займаються. Мене все ще торкає тема «master — slave» у python, та обговорення що такі терміни ображають чорношкірих... Сумую за Perl та обговореннями щодо покращення коду, швидкості виконання, а не бл...ства у вигляді кого що ображати може у мові програмування ....

Щоб ви порадили?

навчатись, збирати, паяти дрони.

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

Джінні норм і у мене з ним лише теплі спогади :) Влітку шукати роботу як на мене — погана ідея, це так само як починати важливі справи у П’ятницю.

Кожна зі сторін хоче завершити переговори з відчуттям, що «нагріла» оппонента

мрак. Це такий собі, як на мене — пострадянський українсько-російський менталітет притришений ідіотизмом.

у кандидата, по суті, лише 2

є ще третій, за можливості — не зв’язуватись з дебілоідними конторами у яких такі підходи і знайти де потрібен реузлтат і іде робота надо здоровим оточенням, здоровою командою.

Яка найбільша проблема, з якою ви стикаєтеся у своєму кар’єрному розвитку?

це були люди які

Просто добре виконувати свою роботу недостатньо. Це я можу сказати як людина, що вже більше 8 років пропрацювала на керівних посадах.

Що значить «добре виконувати роботу»? Твоя відповідь на це питання може сильно відрізнятись від думки твого керівника.

деякі з них це взагалі тема для окремої статті

я б сказав окремих книжок, курсів...

Може ви до ArgoCD не з тієї сторони підійшли?

Хто зна щодо сторін, документації. Все воно є — але часто густо не очевидне і витрачаєш час на тести, налагодження, знаходження рішення...
Оно по дефолту наче просто, але при підключенні типу gitlab через dex + групи + ролі для девів і тестерів — дещо нервує поки розберешся. Так само коли випиляли additionalApplications — трохи крові попили поки дотягнув до 5.0.0 весрії чарту, та об’єднання однії Арго на декілька неймспейсів — тут чесно кажучи не все ще попиляв бо багато нюансів в роботі проекту. Загалом так — норм тула якщо не дуже її кошмарити під потреби менеджменту.

За статтю дякую, от ще б готовий набір навчальних матеріалів по тулах цих :) Бо наприклад ArgoCD — у них я так бачу «сучансий підхід» як і у ElasticSearch де від 1 до 7 версії софт просто перетворився в якийсь дикий мультітул, перш ніж почати проацювати з ним потрібно багато шаманства дізнатись та наук. Час від часу будуть ламатись мізки коли пишеш конфіг і зтикажешся з «namesapace» і не відразу зрозуміло це про кубік неймспейс чи якийсь інший. не очевидно як запустити один Арго на 5 неймспейсів в одному калстері, розподіл прав теж чесно кажучи можна мізки зломати, оновлення версії потрібно робити обережно бо може так статись що потрібно патчити, чистити конфігмапи — бо вирішили певні розділи конфігів винести в окрмесі сервіси як то applications...

PS чи то я постарів, чи то софт реально пишуть і роблять абізяни... Раніше у мене не викликало стільки часі і болю розібратись з +1 технологією щоб вона працювала адекватно.

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

Нащо переписувати?

я може знову втрачаю суть розмови, але як я розумію оцей посил

Дійсно, в компанії бракує або ресурсів чи клепок, щоб це переписати на новий стек.

означає саме переписувати, а тут ви питаєте нащо переписувати...

Тому що Opex.

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

Розумієте про що я?

Чесно — ні, бо є моментами протиріччя у вас самому собі, а також якесь суб’єктивне бачення пов’язане на тренди. Як я вже писав — у мене інший підхід і бачення, так само як і визнавати ти чі інші технології показником рівня компанії, менеджменту тощо.

це не підхід у Agile. Це відсутність архітекта та профанація тіми

Відкриваєм Аджаіл маніфест і читаємо.

Кліента треба вести до мети і здавати проект по її досягненню.

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

PS тут ми можемо довго спілкуватись і кидатись думками/фактами, але поки що я не зловив для себе напрямку, який би пояснював як сучасні тренди збережуть від майбутніх думок що у тебе проект/компанія/менеджмент/архітектор/технарі тощо — не зрілі, не вистачає клепки тощо.

Якщо моя думка про те, що є сучасний стек не сформувалася у Вашому уявленні — вибачайте.

У нас тут різне мачення не в цьому питанні.

Напевно з цього і треба починати: Ваш проект йде через голову.

я б так не скзаав. Для мене я бачу проблему в тому, що клієнт замовляє літак, який йому роблять, тестують, віддають. Далі клієнт просить додати йому до літака ще бассейн, потім систему прорахунку ризиків, потім особисту нафтобазу з якої літак має брати керосин і пішло поїхало. Загалом це такий сучасний трендовий підхід Agail у якого ще й маніфест є і складно думаю бути софтверним архітектором у підході де «Готовність до змін важливіша за дотримання плану».

Слідування трендам це невід’ємна частина ІТ-життя.

кожному своє. Я себе відношу до тієї категорії технарів — коли рішення має бути не трендовим, а вже відпрацьовнним, відстоявшимся, мінімально багів, максимальна кількість людей — які можуть з цим працювати. Мінімальні бізнес ризики на майбутнє з максимальними EOL періодами для софта. Тому що у 2024 роца те, що зараз є трендовим і ви це юзаєте у 2035 може статись так що буде як ви вище писали про незрілі компанії, клепку, менеджмент тощо...

Дійсно, в компанії бракує або ресурсів чи клепок, щоб це переписати на новий стек.

Назвіть будь-ласка конкретні об’єктивні причини того, що компанія зависає на старому софті.

Подивіться на це з боку бізнесу, нашо переписувати те, що вже працює ?
Хто надасть карантії що вчорашній Ansible, який був в тренді через 10 років не здохне як Perl ?
Переписування проекту з Java 7 + Scala на умовний Python, перемикання клієнтів, зворотня сумістність, підтримка легасі і нової версії в плані інфраструктури, коду — це величезний головняк. Клієнти не завжди згодні з оновленнями і подібними рішеннями — в такі часи починається ще й юридична тяжба по умовам надання послуг які прописані в договорах. Компанія починає наймати на роботу додактових девів, менеджерів, аналітиків тощо — для планування потенційной міграції на сучасний стек, що в тренді. Я просто через таке проходив і розумію на скільки це пекельно, складно і тут питання не в тому — що подобається CEO або CTO, а саме бізнес питання і не в одній компанії. Переписаний проект з верогідністю 99.9% буде працювати з новими багами як в самому проекті, так і в інфраструктурі. Тому якщо проект працює і у проекта багато клієнтів — простіше його перевести на KTLO і якщо потрібно доплатити Oracle за підтримку Java і тут копійки в реалності, а з AWS домовитись про свої потреби. В такому режимі можна не витрачати багато грошей, так простіше і довше буде жити.