Як я став AWS Community Builder¶
Кілька років тому це був звичайний DevOps: деплої, скрипти, «чому знову впало». Потім почав глибше копати в Kubernetes і cloud-native — і змінився спосіб думати.
Що змінилось¶
Раніше: один сервер, один додаток, один деплой. Якщо щось падало — дивився логи і рестартував.
Потім почав думати кластерами. Не «де він крутиться», а «як система відновлюється сама». Не «задеплоїти», а «спроектувати платформу, щоб деплої були частиною процесу».
Це не було рішення «давайте зануримось у cloud-native». Просто щоденна робота поступово зміщувала фокус. Більше контейнерів, більше EKS, більше питань типу «а як це масштабувати без болю».
AWS і контейнери¶
Екосистема AWS для контейнерів — це не лише ECS чи EKS. Це ECR, Fargate, Load Balancers, IAM для pod'ів, і купа дрібниць, які треба збирати разом.
Приклад: треба було зберігати ML-моделі, Helm-чарти і Docker-образи в одному місці. Виявилось, що ECR підтримує OCI — можна пушити все в один репозиторій. Написав статтю про це — і це вже був крок до комʼюніті.
Що дає Community Builders¶
Чесно: це не магічна зміна життя. Це доступ до early preview, звʼязок з іншими Builder'ами і з AWS. Можливість задати питання тим, хто вже проходив подібні шляхи.
Обмеження теж є: програма не гарантує карʼєрний стрибок, треба самому вкладати час у контент і спілкування. Але якщо ти вже пишеш, виступаєш або допомагаєш іншим — це природне продовження.
Хто допомагав по дорозі¶
Дякую Max Ivashchenko, Anna Jabłońska-Oszust, Viktor Vedmich, Cherevatenko Vsevolod, Vadym Kazulkin, Anton Babenko — за поради, приклади і мотивацію. І AWS за можливість бути частиною програми в категорії Containers.
Що далі¶
Планую глибше розбирати Kubernetes і cloud-native патерни, ділитись практичними кейсами з production і писати про те, що реально працює. Якщо це тобі цікаво — можна підписатись на LinkedIn або AWS Community.