Інфраструктура програмного забезпечення (до якої я відношу все, що закінчується на *aaS, або щось віддалено схоже на неї) - це дуже цікава сфера, зокрема тому, що (попри те, що кажуть неолуддити) вона з кожним роком стає все кращою і кращою! Мені подобається працювати з чимось, що так швидко розвивається.
За останні кілька місяців я багато думав про те, куди це піде в найближчі 5-10 років, і в моїй голові сформувався список бажань. Цей список є доволі упередженим! Тобто, ви можете з ним не погодитися. Це нормально - це, по суті, мої прогнози, або, принаймні, список бажань. Я не проти, якщо я матиму рацію щодо деяких з них, але не щодо всіх. Отже, розпочнемо.
Створено для задоволення
Знаєте, як паскудне програмне забезпечення буває паскудним настільки, що користувач не може зрозуміти, навіщо його взагалі випустили? Сенсорний інтерфейс, який дуже повільно працює, або програма для бронювання зустрічей, яка змушує вас перебирати можливі дати та заповнювати всю інформацію, перш ніж повідомить, чи є вона доступною. Ми всі бачили такі недолугі рішення, і вони, як правило, недолугі однаково: таке відчуття, що ніхто не користувався продуктом після того, як він був створений, і не сказав: "Гей, це трохи дратує, можливо, нам варто зробити його зрозумілішим?".
У 99% випадків, я думаю, вони опинилися в такій ситуації, тому що хтось склав довгий контрольний список вимог, але в ньому не було нічого, що гарантувало б, що досвід користування буде приємним. Наприклад, хтось почав з того, що обвішав стіну стікерами з написами "як користувач, я хочу...". Що, на мою думку, має логічний сенс - ви можете визначити вимогу, що користувачі повинні вміти робити x, y, z, але ви не можете гарантувати, що користувацький досвід не буде відстійним.
Так чи інакше, я відчуваю, що це стосується приблизно 90% продуктів програмної інфраструктури.
Я маю на увазі, що як користувач, я можу налаштувати статичний веб-сайт в AWS, але це займає 45 кроків в консолі, і 12 з них дуже заплутані, якщо ви раніше ніколи цього не робили. А ще це дуже повільно, і кожного разу, коли я роблю помилку, я опиняюся в якомусь дивному стані, коли, можливо, я щось жахливо зламав і мені, можливо, доведеться починати все спочатку. Прикро, що нинішній стан інфраструктури саме такий.
Можна багато чому навчитися з того, як найкращі компанії створюють споживчі товари. Як вони використовують дані для визначення точок тертя і постійно експериментують зі змінами, щоб спростити роботу. Я маю велику надію, що природний відбір віддасть перевагу продуктам, які легко запускати і якими цікаво користуватися. На першому етапі нам просто потрібно більше альтернатив, а не лише жменька великих напівмонополій. Чекаємо з нетерпінням.
По-справжньому serverless
Скільки вже минуло років з моменту переходу на хмарні технології? Більшість компаній (принаймні ті, з якими я спілкуюся) працюють у хмарі. То чому ж програмне забезпечення все ще поводиться так, ніби хмари не існує?
Слово "кластер" є анахронізмом для кінцевого користувача у хмарі! Я вже працюю в хмарі, де є гнучкі ресурси, доступні в будь-який час. Чому я повинен думати про базовий пул ресурсів? Просто підтримуйте його для мене. Я ніколи не хочу нічого забезпечувати наперед до навантаження. Я не хочу платити за ресурси, що простоюють. Просто дозвольте мені платити за ті ресурси, які я дійсно використовую. Безсерверність не означає, що це віртуальна машина з можливістю розриву, яка зберігає стан свого екземпляра на диску під час періодів простою. Я міг би продовжити, але не буду. Я мрію про світ, де все буде по-справжньому безсерверним. Тобто, я не хочу думати про майбутні потреби в ресурсах, я просто хочу, щоб речі магічним чином справлялися з цим. Хороша новина полягає в тому, що я думаю, що ми насправді наближаємося до цієї мрії з кожним роком!
Привабливість цього полягає в тому, що багато конфігураційних речей зникають чарівним чином. Конкурентна перевага більшості стартапів полягає у створенні бізнес-цінності за допомогою бізнес-логіки, а не планування потужностей та управління ними!
Мало того, мультиоренда - це фактично "безкоштовний обід" з точки зору використання ресурсів, тому будь-яка можливість об'єднати ресурси - це справжня безпрограшна угода. У масштабах центрів обробки даних по всьому світу вона велика - це залежить від того, хто ви, але ви можете радіти або заощадженим гігатоннам CO2, або збільшенню чистого прибутку компанії (думаю, мені подобається і те, і інше!).
Швидко
Я не маю на увазі швидко, тобто швидко обслуговувати запити. У нас є програмне забезпечення, яке чудово справляється з цим завданням! Чесно кажучи, я думаю, що це приголомшливо: ви можете запускати функції та по всьому світу отримувати час відгуку порядку мілісекунд.
Швидкість, якої немає, - це налаштування інфраструктури. Якщо я вношу зміни в консоль AWS, або додаю новий блок в Kubernetes, або ще щось, я хочу, щоб це відбувалося за лічені секунди. Я не прошу мілісекунди! Просто, будь ласка, принаймні зробіть так, щоб це було менше секунди. Якщо ми зможемо обслуговувати запити за мілісекунди, то я не сумніваюся, що ми зможемо це зробити. У нас є технології для завантаження віртуальних машин і контейнерів майже миттєво.
Швидкість має значення, тому що це серйозна втрата часу для інженерів. Мені здається, що я змарнував роки, дивлячись на зміни в інфраструктурі, які мали б почати діяти. Я повернуся до цієї теми через секунду, тому що вважаю її дуже важливою!
Ефемерні ресурси
Майже вся інфраструктура, з якою мені доводилося працювати, ставиться до ресурсів як до чогось, що має існувати нескінченно довго. Якщо я створюю базу даних у хмарі, вона залишається там, і якщо я нічого не зроблю, вона буде вічно засмічувати консоль, і я буду вічно платити за неї гроші.
Раніше я думав, що це нормально! Моє виправдання було таким: якщо ви хочете запустити тестовий набір, просто запустіть базу даних локально, можливо, в контейнері. Для деяких речей це добре, але я дійшов висновку, що це, мабуть, дуже погано:
Створення власної копії інфраструктури, яку можна запустити локально - це багато роботи. Дельта між розробкою та продакшеном стає більшою. Завжди будуть існувати тонкі відмінності в тому, як працює хмарна інфраструктура та локальна. Багато хмарної інфраструктури є пропрієтарною, і її неможливо запустити локально! Моє глибоке бажання - полегшити створення ефемерних ресурсів. Вам потрібна база даних для вашого тестового набору? Створіть її в хмарі таким чином, щоб після завершення роботи з набором тестів її можна було очистити від сміття. Запускайте свої тести на хмарному інфра-середовищі!
Я вважаю, що дебати останніх 5 років виглядають приблизно так:
(Щоб бути чесним на 100%, те, за що я виступаю в цьому блозі, не обов'язково означає негайне впровадження змін на очах у користувачів, хоча я загалом підтримую це з інших причин, не розглянутих в цьому блозі). Я кажу - дозвольте мені використовувати інфраструктуру, подібну до продакшину, наскільки це можливо, протягом усього процесу створення та тестування коду).
Теза про ефемерні ресурси стає в 100 разів вагомішою у поєднанні з попередньою тезою про те, що я можу швидко створювати ресурси. Загальна схема побудови коду полягає в тому, що інфраструктура відокремлена від логіки, а логіка тестується незалежно. Дещо спрощено, ви можете уявити процес розробки як набір вкладених циклів, де час виконання кожного циклу експоненціально погіршується на кожному рівні:
На кожному рівні циклу ставки підвищуються, а цикл зворотного зв'язку сповільнюється. Це має надзвичайно сильний зв'язок з продуктивністю! Головне, на що слід звернути увагу, - це те, наскільки важливо змістити акцент із зовнішніх циклів на внутрішні. Зменшення швидкості ітерацій на порядок суттєво впливає на виконання роботи.
Наявність швидких ефемерних хмарних інфраресурсів дозволило б нам перенести багато інфраструктурних проблем із зовнішнього циклу у внутрішній. Це дозволяє отримувати зворотний зв'язок за лічені секунди або принаймні хвилини, а не години чи більше.
Код, а не конфігурація
Я знаю щонайменше 4 способи взаємодії з інфраструктурою, які я можу придумати:
- Веб-інтерфейс
- Локальна конфігурація, потім запустити клієнт командного рядка, який спілкується з системою
- API, і ви повинні створити клієнт самостійно
- Клієнтські бібліотеки
Перший варіант дуже корисний, але, як правило, лише для початку роботи. Після того, як ви щось налаштували, ви, як правило, відходите від нього як засобу внесення змін, і, можливо, використовуєте його лише для моніторингу тощо.
Локальна конфігурація, як правило, є наступним кроком. Якийсь час це добре, але в половині випадків ви розумієте, що
- Насправді я хочу, щоб цей фреймворк контролювався іншим фреймворком на вищому рівні. У цьому випадку у вас є два (обидва погані) варіанти: показати конфігурацію для обох фреймворків або змусити зовнішній фреймворк динамічно генерувати конфігурацію для іншого фреймворка.
- Вам потрібно генерувати ресурси динамічно, можливо, у циклі for-loop або ще якось.
І раптом ви переходите від YAML до YAML, згенерованого за допомогою Jinja або Handlebars чи чогось іншого. Поступово ви починаєте додавати кастомні функції до цих мов шаблонів, щоб полегшити створення конфігурації. Зрештою, це перетворюється на власну супер-кастомну DSL з власною документацією.
Це дуже дратує! У 10 випадках з 10 я вважаю за краще мати доступ до всього через гарну маленьку клієнтську бібліотеку. Ця бібліотека, своєю чергою, може бути простою обгорткою навколо надійного API. Тепер я можу писати свої власні цикли! Я можу генерувати речі динамічно! Мені не потрібно вивчати спеціальний DSL! Світ знову став щасливішим.
Створено для продуктивності
Я хотів би завершити цю статтю метатезою, яка насправді не є самоціллю, а радше зміною мислення і, можливо, наслідком усіх інших пунктів.
Інфраструктура виглядає так, ніби вона була побудована для розв'язання складних проблем масштабованості та надійності. Це дивовижна інфраструктура, і я в захваті від того, скільки зусиль було вкладено в її створення. Але речі рідко створюються для оптимізації продуктивності розробників. Я думаю, що в довгостроковій перспективі "виграють" ті інструменти, які оптимізовані саме для цього. Насправді це не тільки продуктивність, це також якість, і ці інструменти підштовхують до компромісу між якістю та продуктивністю "вгору і вправо":
Я хочу сказати, що нова крива компромісів дозволяє вам "отримати готівку" від покращень у різний спосіб: можливо, у формі підвищення якості, можливо, у формі підвищення продуктивності, а можливо, у формі поєднання обох цих способів.
Для мене це означає величезну прогалину в можливостях протягом наступних 5-10 років. Я не можу дочекатися, коли інженери вивільнять ще один щабель продуктивності. Існує так багато програмного забезпечення, яке чекає на створення!
Ще немає коментарів