Fast Start to Building on AWS [ukr]

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

Що таке AWS? Звісно, ви знаєте, AWS – це хмарний провайдер. Але зрештою, що таке взагалі хмарний? Хмарний провайдер – це, в принципі, ідея функціоналу, який надає вам можливість використовувати вичислювальні послуги, спеціалізовані сервіси, по суті, хостити у щось, що завгодно в дата-центрах і на інфраструктурі, яка вам не належить, яку ви не обслуговуєте, яку ви отримуєте на той час, який вам потрібен. Нас на сьогодні 32 глобальних регіони, ви їх, в принципі, можете побачити на карті. Є ще кілька планів щодо подальшого розвитку цих регіонів і більше ніж 450 точок підключення CDN, які ми використовуємо для прискорення віддачі трафіку. І насправді, крім цього вже більше двох сотень різних сервісів і функцій, які використовують наші клієнти, фактично, для будь-яких задач в IT-проектах. Але я зараз не буду вам розказувати про всі з них, тому що це дуже багато і, найголовніше, навіщо.

Ми ще не відповіли на питання, нащо взагалі щось робити, щось будувати на AWS. Окей. Я можу вам показати ось таку картинку. Там ви побачите дуже багато логотипів компаній, великих компаній, стартапів, що завгодно. Окей, ми бачимо, що компанії нас обирають, але чому взагалі, з чого починається ідея, що щось в хмарі треба запустити. І тут я хочу трошки поговорити про те, що, на мою думку, найбільш важливе для компаній, які вивчають можливість запустити якусь нову ідею, запустити якийсь новий бізнес або розширити існуючий бізнес на інші сфери. Насправді, мені дуже подобається фраза про те, що швидкість перемагає. Я вважаю, що швидкість – це запорука успіху. І багато є ідей про bootstrapping стартапів і так далі, але майже всі вони сходяться на думці про те, що перша версія вашого продукту, перша версія того, що ви запускаєте, має бути мінімальною. Ну і, в принципі, зрештою, за неї вам... ...згодом має бути соромно. Тому що, якщо вам за цю версію не соромно, то ви, скоріш за все, зробили її надто пізно. І тому, власне, наша робота в AWS, в тому числі, моя робота в AWS, це допомогти вам рухатись якомога швидше. Швидко масштабувати ваш бізнес, прискорити створення нового функціоналу, нових фіч. Уможливити і прискорити експерименти для того, щоб ви змогли швидше знайти продукт – market fit. Допомогти вам швидко прийняти рішення щодо того, куди рухатись, і так само швидко змінювати бізнес. Тобто щоб ви могли в будь-який час, коли ви бачите в тому потребу, повністю змінити все, що ви використовуєте в хмарному середовищі і без будь-яких комітментів. Тому ідея, яку я пропоную використовувати, це те, що якщо у вас є ідея продукції чи функціоналу, найголовніше це не витрачати багато часу на її обдумування, а краще зробити натурний експеримент.

Тобто зробити якийсь легкий research, подивитись на конкурентів, подивитись, що роблять інші компанії, як вони це роблять, а також подивитись, що є у вашого хмарного провайдера, чи вашої команди із доступних інструментів, які вам допоможуть цю ідею запустити. Тому що головна ціль такої вправи — це визначити те, що не варто взагалі на початкових етапах дуже багато часу і зусиль вкладати в конкретну ідею, поки ще не відомо, чи вона вистрілить чи ні. І тому в цьому випадку експериментування в хмарі, мені здається, один з найбільш простих варіантів обійти це обмеження, тому що комітмента нема, pay as you go, запустили щось, в тому числі використавши готові хмарні сервіси, які є у вашого провайдера, для того, щоб не витрачати час на полірування цієї кульки з фольги, і щоб якомога швидше показати продукт ринку і побачити, як ринок на нього відреагує.

Наприклад, ви вирішили запустити сайт в AWS. Добре, сайтів у світі мільйони, користувачів ще більше, тому кожного дня нові сайти запускаються, це можуть бути які-небудь лендінги, які-небудь маленькі прості мікросервісні сайти, а навіть які-небудь лендінги на Wordpress, або ви створили команду фрілансерів і хочете зробити для неї візитку. Вам для цього потрібно, по суті, просто захостити сайт. І не обов'язково для цього там дзвонити чи писати в DigitalOcean чи в Hetzner і заключати контракти на Collocation, чи навіть просто на хостинг. Берете штуку під назвою LightSail, як приклад, яка в собі включає набір компонентів для LempStack, чи для інших популярних веб стеків. Просто берете його як готовий набір, як готову коробку, вибираєте потрібний розмір, тобто кількість ресурсів, можете використати готові шаблони, вже взяти готовий Wordpress, чи Django, чи LempStack, чи що завгодно. Ну або взяти чисто операційну систему і самі насетапити. І все.

З таким підходом ви можете такий простий сайт, таку візитку чи такий лендінг запустити буквально за кілька хвилин. Тобто, власне, оце середовище, коли ви його виберете, буде доступне вам хвилин через п'ять. І ще певний час, в залежності від вашого досвіду, ви витратите для того, щоб ваш дизайн на Wordpress туди закачати. І, в принципі, все. І в будь-який момент, коли ви вирішуєте, що це вам більше не треба, ви його вимкнули і перестали за нього платити.

Окей. Допустимо, ваша ідея запустилася. У вас є багато реєстрацій, власне, прийшов час робити сам продукт. У вас є якась MVP-версія, і ви тепер би хотіли її запустити, показати вашим клієнтам. Дуже часто для того, щоб такі рішення запускати, девелопери їх готують в контейнерах. Тому, як запустити контейнер? Насправді... Багато хто вважає, що якщо ми говоримо про контейнеризовані додатки, про контейнеризовані системи, ми зразу починаємо говорити про мікросервіси. Але, на мою думку, це також неправильно. Тому що навіть Мартін Фаулер, з якого, власне, пішла мода на мікросервіси, який ідею мікросервісів придумав і розповсюди, він сам через кілька років, подивившись на те, що він накоїв, змінив думку. І зробив ще одну програмну статтю, в якій пише, що монолітні додатки — це окей. І, скоріш всього, коли ви щось робите нове, моноліти — це окей. Тому що, якщо у вас невелика команда, порівняно простий додаток, то швидкість розробки моноліта буде швидшою, по-перше. По-друге, швидкість роботи компонентів може бути швидша, якщо вони використовують один одного. Тому що їм не треба звертатися один до одного через мережу. І також монолітна архітектура не є синонімом неможливості масштабування. Тому що, насправді, гарно спроектовані моноліти мають мати можливість досить легко горизонтально масштабуватись. До того ж, навіть говорити про проблеми в масштабуванні на перших етапах не варто, тому що частина стартапів, в принципі, ніколи не переросте цього рівня, коли перед ними виникне проблема масштабування. Тому хороший, нормально спроектований монолітний додаток для вас, в принципі, може добре працювати довгий час. І для цього є багато досить простих сценаріїв. Один із таких, які мені особисто використовуються, якщо у вас, наприклад, вже є код, але і ви, в принципі, не хочете окремо деплоїти якийсь контейнер, оркестратор чи ще щось, то використовуєте рішення під назвою AppRunner. Це фактично менеджерський інструмент, CLI-інструмент, який дозволяє вам деплоїти ваші додатки, контейнеризувати і деплоїти їх прямо з робочого місця програміста. Тобто, з вашого лептопу, з вашого репозиторія. Ви там виконали кілька команд і воно під капотом підняло вам, по суті, запустило ваш контейнер в хмарі. Замість того, щоб окремо робити білд-пайплайн і так далі, просто руками задеплоїли, через 10 хвилин воно вже онлайн. У вас йде на нього живий трафік.

Але окей, ваш стартап процвітає, і вам вже потрібно його масштабувати або вам, зрештою, стає потрібно робити все більше і більше фіч паралельно, у вас збільшуються кількість команд, які гальмують один на одного, і ви переходите до мікросервісної архітектури. Це, в принципі, теж варіант, до якого багато компаній доходять. Тобто, коли ви вирішили це робити, вам вже потрібно задизайнити і модель даних, і інфраструктуру, і комунікацію між частинами вашого минулого моноліту, тобто між мікросервісами, так, щоб вони незалежно масштабувалися, у них був graceful degradation, тобто воно, був гарно влаштований моніторинг і т.д. І якщо у вашій команді багато спеціалістів з контейнерної інфраструктури,то має сенс подивитися в сторону того, як найпростіше можна таку мікросервісну архітектуру захостити. Для цього в AWS є аж два контейнерні оркестратори. Один наш власний Elastic Container Service або ECS, і другий менеджер Kubernetes Cluster. Насправді, моя особиста думка, що ECS набагато простіше для того, щоб почати. Там реально, в принципі, його конфігурація дуже проста, він швидко запускається, сам ECS Cluster не коштує взагалі нічого, на відміну від EKS. Тому це насправді інструмент, який навіть багато компаній, багато моїх клієнтів використовують на рівні з Kubernetes. Тобто одне не означає відсутність іншого. Але якщо у вас є команда, яка вміє менеджити Kubernetes Cluster і так далі, то ви можете його використовувати також в AWS. І щодо самого хостинга, в принципі, я рекомендую вибирати десь так. Тобто, якщо ви хочете якомога простішу оркестрацію, це от варіант в верхньому лівому кутку. Ви використовуєте оркестратор ECS і Fargate, який є по суті Serverless хостером для контейнерів. Якщо вам потрібно більше контролю, якщо вам потрібно якусь кастомну конфігурацію, якісь власні інструменти, які EKS не підтримує, тоді беремо Kubernetes, беремо EKS і використовуємо його.

Як що до Storage. Взагалі, є така загальна думка про те, що Storage безкінечний. Ну, звісно, не варто забувати про те, що хмари як такої не існує. Хмара — це просто сервер, який стоїть не у вас в дата-центрі. Але, дійсно, його можливості масштабування, складно собі уявити. І одним із ключових Storage сервісів, які ми використовуємо, це S3. І S3 — це набагато більше, ніж Storage. Тому що, фактично, це готовий веб-сервер зі Storage разом. Він безкінечно масштабується. Його об'єкти, які там зберігаються, тобто файли, доступні по HTTP. Тобто можна його використовувати напряму для хостинга. Цей Storage зразу доступний. Тобто вам не потрібно якось його наперед замовляти. Просто, як тільки ви файл залили, він зразу стає доступним для скачування. І на додачу до самого Storage і хостинга є ще багато додаткового функціоналу, який допомагає будувати певні функції навколо Storage. Наприклад, починаючи від хостинга. І в тому числі з умовами роботи з Scores і додаваннями редиректів. Також на рівні S3 цього можна зробити. Якщо ви запустили додаток, в якому вам потрібно юзерський контент приймати, тобто давати можливість користувачам завантажувати файли. Ви можете це зробити так, що фактично завантаження буде проходити в обхід вашого додатку взагалі. І по суті користувач буде завантажувати напряму в S3 не додаючи додаткове навантаження на ваш аплікейшн сервер. Якщо вам потрібно знову-таки працювати з юзерським контентом вам часто потрібно якось його обробляти. Починаючи від того, що будувати кілька версій одних і тих же зображень під різну роздільну здатність, наприклад, якщо ви хочете цю оптимізацію робити і закінчуючи модерацією юзерського контенту. Тому так само ви можете побудувати по суті, такий ланцюжок процесінга, який буде слухати події які генерує S3 на факт завантаження файла. І оці події на них ви робите якусь вашу реакцію. Від якихось автоматичних там імейдж-ресайзерів і так далі, закінчуючи постановкою задач в чергу на модерацію. І так далі.

S3 під капотом так само розподілений і розкиданий по континентам. Тому при необхідності ви можете налаштувати віддачу контенту з S3. Так, щоб вонабула так само через CDN та була максимально близька до кінцевого користувача. Цим користуються наші клієнти, які використовують S3 для хостінга медіаконтенту. Відео, музика і так далі.

Далі. Ви, напевно, вже багато чули про Serverless. Serverless, як ідея, як ідеологія, це ідея про те, що ми взагалі не оперуємо поняттями аплікейшн сервера чи якимось інфраструктурними компонентами, коли нам потрібно якийсь функціонал виконати. Ми думаємо в режимі бізнес-задач, або в режимі фіч. Тобто ми не кажемо про те, що нам потрібно запустити аплікейшн сервера. Ми думаємо, окей, нам треба зробити ось таку обробку даних. Або ось такий набір тригерів, які будуть виконувати якийсь документообіг або ще щось. І якщо ви звикли так думати, якщо ви думаєте івентами, якщо ви можете в себе в голові або на whiteboard намалювати структуру контекстів, тобто який компонент за що відповідає. Яка буде модель даних всередині кожного з компонентів і між ними. Або як буде виглядати потік даних. Хто його ініціює. Які процесінгові етапи є. Де можуть бути потрібні якісь ретраї або екшини і так далі. То ви уже фактично думаєте в serverless. Тому що потім, коли ви це все намалювали, ви просто берете і на місці кожного з блоків ставите той чи інший serverless сервіс. В AWS їх багато. Починаючи від стораджа і комп'ютета. Я думаю, ви всі чули про AWS лямбда і про хостінг коду. І закінчуючи великою кількістю сервісів, за допомогою яких можна створювати, керувати, оркеструвати потік даних або будувати якісь, скажімо так, алгоритми або стейт машини обробки ваших задач кожен з компонентів яких буде серверлес. До того ж, одне не обов'язково означає відмову від іншого. Тобто, не обов'язково мати або лише serverless рішення, або лише serverfull, скажімо. Вони легко працюють разом. Наприклад, якщо у вас є ситуація, коли вам потрібно розвинути існуючий функціонал і ви не хочете багато вкладатися в переробку чи доробку вашого монолітного додатку, який і так працює чудово. Ви можете використати serverless рішення для добавки цих функцій. Наприклад, є у вас форма відруків на ваші продукти чи на ті товари, які ви продаєте. І ви хочете, наприклад, зробити якийсь процесінг цих відруків. Окей. На клієнтському рівні ці відруки створюються. Ці відруки потрапляють в якусь серверлес базу даних. Вам не треба навіть зберігати їх там же, де ваша інформація про продукти. Просто зберігаєте їх окремо. Далі по самому факту запису відруків у базу даних, може тригеритися інший процес, який, наприклад, перекладає ці відгуки. Якщо ви підтримуєте локалізацію в багатьох мовах. Або, наприклад, якщо ви хочете робити якийсь sentiment аналіз. Тобто аналіз емоційного направлення відгуків. То дуже багато систем, які це дозволяють, працюють з англійською мовою. Тому якщо ви використовуєте, наприклад, коментарі з української мови, чи з грецької, чи ще з якоїсь, завгодно ви їх перекладаєте на англійську. Далі використовуєте sentiment аналіз. Або, наприклад хочете дати можливість в відгуках завантажувати фотографії продукту, наприклад.

Окей. Те саме. Ще одна serverless функція і S3, який так само, по суті, є serverless storage. Завантажуєте туди. І все працює. Так само, якщо ви сильно хочете реагувати на коменти. Через sentiment аналіз ви можете знаходити відгуки від незадоволених користувачів і зразу, якось на них реагувати. Тобто, починаючи від просто відправити повідомлення, яке прийде комусь на е-мейл, вашій службі підтримки клієнтів, або ще комусь. Тобто, весь цей функціонал по суті, можна додати уже на базі існуючої системи. На базі існуючого e-commerce рішення. Просто ми добудували до нього з боку систему зберігання і обробки відгуків.

Ми бачимо, що тут в багатьох місцях чотири рази на картинках лямбда функція. Тому, якщо підсумувати, для чого вона може бути корисна. В першу чергу, це для задач, які триггеряться чимось.Тобто, не постійно працюючи, а запускаючись якимись івентами. В принципі, це не дуже сильно залежить від того, яку мову програмування ви використовуєте. Тому що ми підтримуємо інтерпретовані мови JavaScript і Python. І компільовані Golang, Java, Rust, багато інших. І головна ідея, що ці функції мають бути незалежними одне від одної і вам краще тримати розмір і обов'язки цих функцій чітко розділеними. Щоб не намагатися зробити весь можливий функціонал, зробити спагетті з купи обробки різних варіантів юзерського вводу в одній функції. Тому що вона стане важкою і її складно буде підтримувати. А замість того, функція кожної конкретної лямбда функції, задача кожної конкретної ламбда функції, має бути дуже чітко обмежена.І ви маєте боротися з ідеєю написати, one function to run them all. Замість цього, чим більш вони будуть деталізовані, тим швидше вони, зрештою, будуть працювати.

Далі, якщо ви вирішили, що вам потрібно для вашої ідеї збудувати мобільний додаток для клієнтів. Але у вас немає особливого досвіду в цьому. У AWS є конструктор мобільних додатків. AWS Amplify - це набір багатьох компонентів там починаючи від девелоперських інструментів і готових бібліотек, закінчуючи її UI компонентами і обв'язкою навколо неї аналітика, моніторинг і так далі. З цих компонентів можна зібрати дуже багато різних користувацьких сценаріїв, взявши просто готову бібліотеку. І зразу ж бекенд для цих додатків можна захостити в тому ж самому сервісі Amplify. За замовченням додатки підтримують різні операційні системи, різні види девайсів, різні розміри екрану і так далі. Це все працює з коробки. Також ви отримуєте готову адмінку, в якій ви можете робити певну аналітику, івенти збирати від користувачів мобільного додатку. І це все робити. Це, по суті, такий досить хороший конструктор. Звісно, він не універсальний. Тому моя головна ідея в тому, що якщо ваші сценарії використання, то, що ви хочете зробити, вкладаються в ці готові компоненти Amplify, і у вас немає своєї командної мобільної розробки, і ви хочете швидко зробити якусь цю апку, Amplify до цього чудово підходить. Якщо ви хочете зробити якусь кастомну апку, вам потрібно щось, що Amplify не вміє, тоді, звісно, наразі він тут не підійде. Але тому Amplify дуже часто популярний так само у стартапів, які фокусуються на мобільній аудиторії. Тому що вони досить швидко можуть зробити кросплатформний додаток, який буде достатній для пілотування своєї ідеї.

Також, в нас зараз довкола нова парадигма, це все про AI. Тому, якщо у вас, знову таки, своїх спеціалістів немає, але ви вважаєте, що певні AI, ML функції вам потрібні чи допоможуть вашому продукту, ви їх можете досить просто додати сюди. Цих сервісів AWS дуже багато. Я покажу буквально три з них, але їх набагато більше. Головна їх ідея в тому, що AWS хоче демократизувати ці AI-сервіси таким чином, щоб їх могли використовувати в проектах, в яких немає великої кількості AI-спеціалістів, щоб побудувати їх самостійно. Тому я почну з кількох прикладів, які найбільш популярні на українському ринку насправді. Почну з Amazon Recognition. Це Computer Vision Service, який аналізує зображення та відеопотік. Щодо зображення, він може, в принципі, розмічувати фотографії, тобто знаходити різні об'єкти на них, знаходити обличчя на зображеннях, даючи певну інформацію про обличчя, починаючи від біоданних, типу вік, гендер і так далі, закінчуючи аналізом емоцій, які люди не показують на фотографії. Також досить часто використовується функціонал порівняння зображень і порівняння обличчя. Цей сервіс взагалі використовується для ситуації, коли вам потрібна якась авторизація. Наприклад, FacePay від PrivatBank також використовує цей сервіс як один із компонентів для того, щоб ви могли заплатити за покупки з використанням FacePay. DetectText, OCR, це все працює. Тобто, інтеграція всіх цих сервісів – це інтеграція на рівні API викликів. Тобто, вам не потрібно власне свою Computer Vision модель тренувати або використовувати існуючу. Просто по API звертаєтесь до Recognition і він вам відповідає.

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

І, напевно, один із найцікавіших сервісів в цій сфері стосується теми Generative AI. Ви, звісно, чули і бачили ChatGPT, Midjourney, Dall-e, будь-які моделі, які або трансформують текст в текст, або мультимодальні моделі, які або аналізують зображення, переводять в текст, або аналізують текст, будують з цього зображення. AWS зробив сервіс під назвою Bedrock. Це сервіс, який дозволяє вам хостити ці моделі і підключати їх до ваших сценаріїв, тобто, до ваших додатків. Знову-таки, через API. Тому що замість цього, щоб обмежувати себе одною конкретною моделлю, ви за допомогою Bedrock можете вибрати із багатьох різних венторів, в тому числі, із цікавого Anthropic Labs з моделями Claude. І я чому їх обвів, тому що це, напевно, одна з найбільш популярних моделей на нашому ринку. Тому що там Claude 2 і Claude 2 Instant, вони насправді досить непогано працюють з текстами українською мовою. Тобто, звісно, зараз у нас іде гонка стартапів, які роблять моделі. Побачимо, що тепер з OpenAI буде, з їхніми змінами, які буквально позавчора відбулись. Але крім OpenAI є ще купа різних стартапів, які будують моделі. Тобто, ці моделі всі також будуть зав'ятись в Bedrock. Тому, в принципі, маючи інтеграцію з ним, навіть зможете заміняти моделі без, по суті, переробки ваших додатків. Ще важливою особливістю Bedrock є те, що якщо ви хочете використовувати моделі, дотренувати фондейшнл моделі на ваших даних, тобто взяти, не знаю, той самий Claude 2, і згодувати йому вашу інформацію про ваш продукт. Якщо ви хочете, наприклад, створити AI-асистента для саппорта. Ви би не хотіли, щоб внутрішня інформація про вашу систему стала доступна комусь.

Тому тренувати публічно доступні фондейшнл моделі не дуже безпечно. В цьому випадку Bedrock допомагає таким чином, що, по-перше, ви можете зробити весь процес тренування, обробки цих даних і дотренування фондейшнл моделі на AWS без великої кількості трудозатрат. І, по-друге, ця модель з вашими даними лишається лише ваша. Тобто вона лишається в рамках вашого AWS-аккаунта. Вона не використовується для тренування чужих моделей і так далі. Ви можете бути впевнені, що навіть якщо ви туди завантажите якусь комерційно важливу інформацію для вас, вона буде safe and sound. Це, до речі, також дуже популярний сценарій зараз, напевно, один із найпопулярніших. Коли комбінація використання Bedrock і Kendra. У нас є сервіс Kendra, це пошуковик. Тобто ви його підключаєте, в тому числі, до on-prem сторіджів, до файлових сховищ, до чого-небудь де у вас лежать ваші документи Word-файли, PDF, HTML-файли, що завгодно. І використовуєте Bedrock як інтерфейс для пошуку. Тобто ви, з'єднавши цих два сервісами разом і давши Kendra проіндексувати ваші документи, ви отримуєте, по суті, якби майже бібліотекаря, який відповідає на питання людською мовою і шукає інформацію по ваших ресурсах. Для великих компаній це зараз дуже актуально. Саме багато стартапів продовжують експериментувати в цій сфері.

Окей, про сервіси поговорили, їх там ще, я ж кажу, їх там майже дві сотні, тому нам, напевно, доби не вистачить про всі розказати. Але, здається, я ще обіцяв трошки про Business Value пройтись. Тому давайте про це поговоримо. Чому взагалі я вважаю, що у хмарних послуг є певний Business Value? Тому що, окей, ці цитати наших клієнтів, вони можуть звучати трошки такими дуже загальними, тому що вони, звісно, не обов'язково підходять до кожного з випадків, але вони дають ідею про те, яким чином ви або зберігаєте гроші, або прискорюєте ваш розвиток з використання хмарних послуг. І насправді більша частина наших клієнтів свідчить про те, що використання хмарних послуг в основному впливає на продуктивність роботи колег. Тобто навіть, власне, фінансова вигода від того, що хмара – це еластичність, що ви там легко використовуєте лише ті ресурси, які вам потрібні на даний момент, це навіть не основний фактор. А основний – це все-таки підвищення бізнес-продуктивності. І якщо ми розглянемо наш фреймворк, який говорить про те, які взагалі вигоди або які корисні якості у хмарі є. Ми бачимо, що починаючи від найпростішого – від збереження коштів, за рахунок того, що у нас хмарні ресурси масштабуються, і ви в тому числі можете запускати стільки ресурсів, скільки потрібно для конкретного користувацького трафіку. І також використовувавши різні моделі оплати за них, також зекономити на цьому гроші. Але крім цього є ще продуктивність ваших співробітників, зменшення ризиків, зв'язаних з operations, і швидкість змін, швидкість прийняття нових рішень. І наприклад, якщо ми говоримо про ризики. Взагалі в хмарних послугах, хмарних сервісах вбудовано міри безпеки. Тобто за замовчування у вас вже є певний рівень безпеки, чисто через використання хмари. Також в кожного із сервісів і в кожного із систем є свій моніторинг. Тому, наприклад, вам не потрібно думати про те на початку, як свій моніторинг запускати. Ви досить нормально можете жити деякий час чисто на моніторингу, який надає сам AWS. Більшість сервісів мають можливість або якийсь вбудований резілієнс ввімкнути. Наприклад, щоб під час відмови одного з компонентів, він автоматично перезапускався. Або намонтаження переходило на інший компонент.

Також є можливість створювати бекапи цих сервісів. Буквально кількома кільками мишки, або одною-двума CLI командами ви можете створити бекап план для всієї організації. Але крім цього є ще досить важливі речі, про які не часто задумуються. Наприклад, те, що велика частина сертифікацій, починаючи від HIPAA compliance, PCI DSS, закінчуючи Fendramp, і там їх так само більше сотні, вони вказують, що ці сервіси є за замовленням сертифіковані. Тому, наприклад, якщо вам потрібно проходити сертифікацію для роботи з якимись даними, використання AWS для вас дає переваги. Так само, наприклад, якщо ви проходите due diligence перед IPO. Ми маємо нашого клієнта, який, в принципі, вирішив мігрувати в AWS, через те, що, фактично, це великий надійний партнер, з яким, як вони виразились, не соромно ходити на IPO. Тому що, коли вони робили Section 2 filling на нью-йоркській біржі, там потрібно описати всіх контрагентів і партнерів. І уявіть собі, наприклад, що там ваш hosting provider, там з'являється який-небудь там servers.com, все нормально і тут раптом виявляється, що в цього hosting provider, скажімо, зв'язки з росією, власники з росії, наприклад. Це зразу стає негативним фактором, в тому числі, для вашої due diligence. Чи це для IPO, чи це для emerging equation і так далі. І якщо ми вже говоримо про due diligence, то з нашого досвіду виходить, що аудитори знають AWS. Тому велика кількість аудитів, які наші клієнти проходять, проходить по досить стандартизованим практикам, тому що аудиторські компанії вже знають добре про хмарні послуги, знають про хмарні архітектури. І, в принципі, сценарії аудитів значно спрощуються і скорочуються в часі. Це чисто з нашого особистого досвіду.

Стосовно продуктивності важких співробітників. Окей, ми говоримо, що вам не треба адміни для того, щоб самі фізичні сервери використовувати, але давайте будемо чесними. Ви так само, скоріш всього, навряд чи, володієте своїм дата-центром. Навіть ви його орендуєте в якогось провайдера дата-центру. Для вас це не актуально. Але що для вас може бути актуально? Це те, що хто б що не казав, але AWS – це один із стандартних дата-центрів. Тому спеціалістів, які знають AWS, на ринку багато. І в тому числі, і за те, що AWS – це такий стандарт, ваша інфраструктура, яка буде збудована на AWS, буде все одно відповідати якимось стандартним підходам, які ви в ідеалі розробите разом зі мною і з моїми колегами. І це означає, що при потребі розвитку команди у вас не буде дуже багато онбордінг-часу, вам не треба буде дуже багато пояснювати, чому ми саме так зробили, а не інакше. Тому що ви все будете робити по хмарним стандартам насправді. І це дозволяє, в тому числі, зменшити баз-фектор. Тому що ваша інфраструктура буде стандартизована, і ви не будете залежати від знань, які могли бути сконцентровані в одному чи двох співробітниках, які не скейляться.

Про інновації я вже трошки говорив. Тобто, з AWS можна досить просто вибрати, почати і змінити інструменти під кожну задачу. Це Software Managed Infrastructure. Тобто, для того, щоб вам запустити віртуальну машину, це один API-виклик, а не підписання контракта з хостингом. Так само, щоб її зупинити, це один API-виклик. Також через AWS ви можете отримувати доступ до спеціалізованого заліза. Починаючи від серверів з відеокартами, які зараз для ML потрібні, закінчуючи доступом до конкретних технологій, як я, наприклад, показував Computer Vision, або GNI моделі через Bedrock. Тобто, доступ до цих технологій ви просто отримуєте через API з використанням AWS.

І, як казав ось цей поважний дядько, це наш CTO, доктор Вернер Вогельс, «You build it, you run it». Я люблю ще додавати туди «You pay for it». Тобто, що це означає? В хмарі ви маєте готовий набір інструментів, для того, щоб робити бюджетування. Ви маєте прозорість коштів, ви можете прорахувати бюджетно-командуючі проєкти, або вартість конкретної фічі. Ви можете створити так званий Budget Reservation. Тобто, можете вказати, скільки грошей має використовувати якась група ресурсів. Чи в одному аккаунті, чи по тегам і так далі. Ви можете вибрати, чого буде цей бюджет стосуватися. Створити алерти. Мати дешборд, на якому буде показуватись бюджет різних груп. Це можуть бути бюджети на команду, або бюджет інфраструктури, або бюджет на проект, наприклад. Так само і мейли на це отримати і так далі. Тобто, бюджетування і прозорість хостів – це ще одна велика перевага, яку вам хмара дає за замовчування. Сподіваюсь, вам було цікаво. Якщо так, то маю для вас один цікавий анонс. Хочу вас запросити до ком'юніті під назвою AWS CTO Fellowship. Це ком'юніті, в якому зараз близько 4 тисяч CTO. Це invite-only ком'юніті. Тобто, туди потрібно вступати, довівши, що ви, власне, являєтеся CTO, або Chief of Engineering і так далі. В першу чергу, це розраховано на CTO із стартапів. Якщо вам цікаво, будь ласка, відскануйте QR-код, потрапите на сторінку з усією потрібною інформацією. Дуже дякую за те, що дали мені можливість виступити перед вами. Якщо маєте 5 секунд вашого часу, будь ласка, відкрийте цей QR-код і напишіть невеликий фідбек на цю доповідь. Дуже дякую. Сподіваюсь, вам було цікаво. І давайте перейдемо до запитань.