Перехід від локальної до SAAS

Перехід локальної розгорнутої програми до (потенційно багатопотенційної) програми SAAS, що працює у хмарі,-це складна операція, яку не варто недооцінювати. Ця стаття являє собою короткий підсумок деяких речей, які ми дізналися в Aprimo, пройшовши двічі всю цю вправу з двома програмами Enterprise. Ми не обговорюємо ліцензування або вплив на бізнес, а зосереджуємось виключно на технічних та операційних проблемах.

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

Підтримка декількох хмарних платформ

Якщо ви плануєте підтримувати декілька хмарних провайдерів (Azure, AWS, Google Cloud …), або якщо ви плануєте також додати свої нові функції до локальної версії, то вам потрібно врахувати деякі речі. рахунок:

Набір функцій: Це особливо важливо, якщо ви хочете використовувати одну або кілька служб SAAS. Різні послуги означають різні можливості. Приклад: перекодування відео за допомогою Amazon Elastic Transcoder поводитиметься інакше, ніж виконання тієї ж операції на Azure Media Services. Обидва можуть підтримувати різні формати файлів, різні коди, якість згенерованого файлу може бути різною, по -різному працювати з субтитрами … Це означає, що вам потрібно або розвиватися для найбільшого спільного знаменника з усіх платформ, або вам потрібно почати диференціювати ваші функції залежно від платформи, на якій ви працюєте. Перший варіант обмежує ваш набір функцій. Останнє збільшує складність розробки.

Розвиток: З точки зору розвитку, усі ці послуги повинні впроваджуватися, перевірятися та підтримуватися окремо. Вони можуть мати не тільки різні API, вони навіть можуть вимагати іншої архітектури, тому відмінності у вашому коді, дизайні, тестуванні та розгортанні можуть бути значними.

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

Операції: З точки зору операції, усі ці послуги та платформи повинні підтримуватися та контролюватися окремо. Це збільшує складність експлуатації та витрати. Для кожної платформи вам потрібно налаштувати та керувати мережею, безпекою, резервними копіями, відновленням після аварій, аналізом витрат, оповіщенням …

Випуск: У Azure випуск вашого програмного забезпечення може означати використання таких речей, як Azure DevOps. Увімкнено, AWS CodeDeploy. Локально ви могли використовувати пакети інсталяторів Windows. Поки ви дотримуєтесь лише однієї з цих платформ, напевно, нормально використовувати будь -яку з цих технологій. Однак, якщо вам все -таки потрібно підтримувати декілька платформ, ви можете спробувати максимально стандартизувати його, щоб забезпечити керування лише однією річчю. Наприклад, шляхом запуску програми в контейнерах та розгортання за допомогою таких інструментів, як Puppet або Chef.

Архітектурно: складніше оптимізувати для певної платформи (будь то локальна чи будь-яка хмарна платформа). Це може означати погіршення продуктивності, зниження доступності та більші витрати на час виконання. Вихід без сервера буде особливо складним, якщо вам також потрібно буде підтримувати локально.

Багатоквартирна оренда

Рішення перетворити додаток з одним клієнтом на додаток з кількома клієнтами впливає набагато сильніше, ніж ваша кількість серверів.

Можливості налаштування. У середовищі з одним клієнтом набагато простіше запропонувати розширені можливості налаштування, оскільки кожен розгорнутий екземпляр можна налаштувати відповідно до потреб кожного клієнта. Хоча це функціонально простіше, оперативно це ускладнює ваше життя, оскільки важкі налаштування ускладнюють дотримання цілей рівня обслуговування. Наприклад, якщо запити починають не працювати з HTTP 500, як ви впевнені, що це через ваш код, а не через певну настройку?

Експлуатаційні витрати. Запуск середовища з одним орендарем також впливає на ваш моніторинг та оповіщення, оскільки щоразу, коли з’являється новий орендар, буде додаватися більше ресурсів, які необхідно контролювати, захищати, створювати резервні копії, повідомляти про …

Вплив масштабування. У середовищі з кількома клієнтами кількість користувачів із відкритим сеансом на веб-сервері може бути значно вищою, ніж у одному середовищі клієнтів. Залежно від вимог до пам’яті вашої програми, це може створити вузьке місце. Якщо ваша програма зберігає багато даних в пам’яті (або в стані сеансу, або в іншому кеші), оптимізація може бути в порядку. Крім того, веб-програми, які потребують спорідненості до сеансу, ускладнять (автоматичне) масштабування та випуск без простоїв, оскільки може бути складніше вигнати користувачів з певного сервера. Вирішенням цього може бути збереження стану вашого сеансу поза процесом, але це може спричинити проблеми з продуктивністю та потенційно серіалізацією.

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

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

Вплив на безпеку. У середовищі з кількома орендарями один веб-сервер буде використовуватися кількома орендарями. Отже, будь -який інструмент, який міг би надати клієнтам доступ до даних іншого замовника, повинен бути видалений або перероблений. Наприклад, в одному з наших додатків у нас був застарілий обробник HTTP, який адміністратори клієнтів могли використовувати для очищення деяких статичних кешів. У середовищі з кількома орендарями статичні кеші містять інформацію про кількох орендарів, тому цю інформацію потрібно було видалити. Неопубліковані виклики API, які ви використовуєте лише внутрішньо, також можуть спричинити ризики.

Використовуйте поетапний підхід

Це очевидне: не намагайтеся заново архітектурувати свою програму, відходити від віртуальних машин, змінювати спосіб входу, змінювати спосіб випуску, забезпечувати відмову після відмови … і все це з першого дня. Надто багато чого навчитися, занадто багато речей, які потребують іншого підходу та мислення такої кількості людей в організації.

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

Стратегія випуску та автоматизація тестування

Підготовка до випуску – одна з перших речей, на яку слід зосередитися. Не чекайте, що він стане ідеальним з першого дня. Крім усього іншого, може знадобитися деякий час, щоб правильно назвати і зрозуміти, де ввести логіку. Вам потрібно переконатися, що випуск легко модифікується, перевіряється та чи працює він належним чином із вашою стратегією розгалуження.

Автоматизація. Автоматизуйте весь випуск з першого дня. Якщо вам що -небудь потрібно зробити спочатку, це ось що. Без цього у вас немає шансів: випуски займуть занадто багато часу, людські помилки спричинять більше проблем, розгортання ніколи не будуть по -справжньому послідовними … Як мінімум, вам потрібно мати повністю автоматизований конвеєр безперервної доставки, який вимагає нуля ручне втручання одразу.

Без простоїв. Якщо ви переходите з локальної бази на SAAS, можливо, вам доведеться внести зміни до свого випуску та способу випуску функцій, щоб переконатися, що ви можете робити випуски без простоїв для своїх користувачів. Наприклад, для оновлення бази даних може знадобитися інший інструментарій та/або інший процес, щоб гарантувати, що ви зможете розгортати її без простоїв. Можливо, вам доведеться оновлювати файли JavaScripts та CSS, не змушуючи користувачів перезавантажувати сторінки у веб -переглядачі. Або, можливо, повідомлення у чергах версовані, щоб старі слухачі не сприймали нові повідомлення …

Часто випускайте. Ви можете звільнятися кожні 3, 6 або навіть 12 місяців у локальному світі. У SAAS більше немає такої розкоші. Клієнти не тільки вимагатимуть від вас швидшого впровадження функцій, але, що важливіше, внутрішні технічні та експлуатаційні причини також підштовхнуть вас до більш частих випусків. Частіші випуски зменшують ризики ваших випусків (великі випуски є більш ризикованими, ніж маленькі випуски). Більш часті випуски дозволяють швидше виправляти помилки. Виконання більш частих випусків приверне увагу і змусить вас оптимізувати всі болючі точки у вашому SDLC: як ви визначаєте вимоги, проектуєте, тестуєте, плануєте, визначаєте етапи …

Автоматизуйте тестування. Якщо ви випускаєте лише кожні 6 місяців, може бути нормально провести два тижні в циклі контролю якості. Але якщо ви випускаєте щомісяця, щотижня або навіть щодня, то два тижні в QA просто більше не скорочуватиметься. Тому перемістіть тестування ліворуч і використовуйте автоматизацію замість тестування вручну. Це може означати, що автоматизовані тести мають бути створені після встановлення фактичних функцій. Це також може означати, що ваша команда з тестування якості/тестування має почати працювати по -іншому і, можливо, доведеться навчитися писати код замість тестування вручну.

Стратегія розгалуження. Оскільки ви випускаєте частіше, функції, можливо, доведеться розділити на кілька менших етапів. Ви не можете дозволити собі відкрити філію функцій протягом 6 місяців. Постійне оновлення цієї гілки буде не тільки складним, оскільки зміни інших розробників у якийсь момент почнуть конфліктувати з вашою. Але випуск речей, які розроблялися протягом шести місяців, також несе величезні ризики. Тому довготривалих гілок функцій краще уникати.

Крива навчання. Для нових функцій може знадобитися нова інфраструктура: послуги, віртуальні машини, контейнери, бази даних SQL, черги … Усі ці ресурси потрібно розгорнути, а отже, вимагати оновлення вашого випуску. Найбільш масштабоване рішення полягає в тому, щоб ваші команди розробників відповідали за оновлення випуску. Однак більшість розробників не звикли працювати з цими технологіями, тому внесення цих змін для більшості ваших команд стане кривою навчання.

Продуктивність та доступність

Ось деякі речі, які слід враховувати, що впливають на продуктивність та доступність.

Відновлення після відмови. Можливо, у вашому локальному середовищі з одним клієнтом було нормально мати частини вашої програми, які не можуть відновити після відмови. Швидше за все, клієнти не були готові платити за обладнання. З вашої точки зору, тільки цей єдиний клієнт постраждав би, якби сервер все одно вийшов з ладу. У середовищі з кількома клієнтами це більше не є варіантом. Там час простою служби означає, що всі клієнти не працюють. Можливо, будь -який фрагмент вашого коду, який не підтримує масштабування або провал, може бути доведено адаптувати.

Стійкість. Припустимо, що будь -яка залежність знизиться в хмарі. Будь то бази даних SQL, сховище, сховища ключів … Ви повинні створити більшу стійкість у своєму коді, щоб впоратися з тим, що будь -яка з ваших залежностей може бути недоступною. Для SQL Server вам потрібно оновити код, щоб мати справу з тимчасовими збоями. Інші послуги (наприклад, сховища ключів) можуть мати обмеження щодо швидкості, з якими ви можете зіткнутися, якщо ви занадто балакучі. Для останніх може знадобитися розміщення кешу перед цими службами …

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

Канали зв’язку. Якщо ваші клієнти спілкуються з вашим сервером через те, що не використовує порт 80 (HTTP) або 443 (HTTPS), вони можуть більше не працювати (надійно).

Довготривалі запити. Ваша застаріла програма може мати певні сторінки, які можуть бути налаштовані так, щоб дозволити більш тривалий час очікування виконання (наприклад, для підтримки деяких повільних запитів). Ці речі, можливо, доведеться реорганізувати, оскільки вони ускладнюють виявлення проблем із продуктивністю. Ви можете вирішити виключити певні маршрути з моніторингу продуктивності, але тоді жодна проблема з продуктивністю на цих маршрутах ніколи не буде виявлена. І ці запити також зменшують масштабованість ваших веб-серверів. Усі ці тривалі запити блокують потоки, які, як тільки у вас є достатня кількість користувачів, стають проблемою. Можливо, вам доведеться розширити веб-сервери швидше, ніж ви очікували.

Можливості налаштування

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

Локальний доступ. Наявність локальних файлів конфігурації більше не може бути варіантом:

Клієнти більше не матимуть доступу до цих файлів конфігурації. З міркувань безпеки або дотримання вимог багато ваших внутрішніх працівників, яким може бути доручено застосувати ці налаштування, також можуть більше не мати до них доступу. Цю конфігурацію потрібно перемістити до чогось (до інтерфейсу користувача або API), до якого обидва мають доступ.

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

Локальні файли конфігурації також несумісні з масштабуванням. Зміна одного параметра конфігурації може означати оновлення його на 20 серверах.

API. Усі API, якими повинні користуватися ваші клієнти, мають бути перетворені на REST API. Якщо у вас все ще є налаштування, які вимагають, наприклад, ваших .NET API або бібліотек класів Java, то всі ці налаштування потрібно або видалити, або змінити, щоб вимагав веб -API.

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

Безпека та правове забезпечення

Безпека стає набагато важливішою в контексті SAAS, тому що тепер ви несете відповідальність за дані: їх послідовність, резервні копії, безпеку … Ось кілька способів, які це вплине на вас:

Файли журналу.

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

Люди, яким потрібно проаналізувати проблеми, можуть більше не мати доступу до локальних файлів журналу. Крім того, наявність їх локально значно ускладнює аналіз у горизонтально масштабованому середовищі, оскільки вам потрібно знати, на якому сервері дивитися. Крім того, оскільки сервери/послуги/контейнери можуть бути оновлені під час випуску, ви можете навіть не мати журналів попереднього випуску, якщо зберігати їх локально. Ви можете вирішити багато з цих проблем, використовуючи такі інструменти, як Azure Log Analytics або AWS Log Analytics, щоб об’єднати ці файли журналів у центральному сховищі, але проблема з цими інструментами полягає в тому, що вони можуть відставати на кілька секунд або хвилин, і вони поставляються з вартість. Залежно від того, наскільки детально ваш журнал ведеться, вартість може бути значною.

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

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

Приховати інфраструктуру. Будь -який інтерфейс, API, документація …, що відкриває все, що стосується інфраструктури, яку ви використовуєте всередині, має бути приховано або видалено. Найважливіше для підтримки будь -якого середовища SAAS у керованому стані – це те, що ви повинні мати можливість контролювати та автоматизувати інфраструктуру та конфігурацію, яку ви використовуєте. Розкриття цього клієнту не тільки впливає на вашу керованість, але й створює ризики для безпеки.

Доступ розробника. Часто, коли виникає проблема, вам потрібні дані або конфігурація клієнта, щоб мати можливість відтворити проблему. Особливо з важко відтворюваних питань. У SAAS ваші клієнти можуть попросити вас договірним чином обмежити тих, хто може чи не може отримати доступ до їх бази даних. Це означає, що ваші розробники можуть не мати доступу до даних клієнта, щоб відтворити проблему.

Відкрите джерело. Можливо, ваша програма використовує десятки компонентів з відкритим кодом. В даний час практично неможливо розробити що-небудь, не використовуючи нічого, що не є відкритим кодом (припустимо, що ви цього хотіли :)). Для SAAS вам доведеться вийняти та замінити будь -яке програмне забезпечення зі смаком GPL, щоб уникнути юридичних наслідків. Можливо, вам доведеться налаштувати процес, щоб бути в курсі подій, оскільки будь -які відомі вразливості у всьому, що ви використовуєте, зараз також можуть стати вразливістю для вас.

Операції

У цьому розділі пояснюються речі, які слід враховувати при створенні оперативної групи.

Розум операцій. Виконання операцій вимагає певного мислення, і на даний момент ви можете не мати цих людей на борту. Не очікуйте, що ваші розробники виконуватимуть операції. У них інший склад мислення, і вони повинні. Розробник зосереджується на довгостроковій керованості платформи. Це означає, що будь -яку помилку потрібно виправити належним чином. Оперативна особа повинна зосередитися на оперативній доступності. Його основна увага – вирішити проблему ЗАРАЗ. Цей конфлікт має бути. Розробник часто отримує задоволення від функцій будівлі. Операційна людина може отримати задоволення від вирішення проблеми. Можливо, ваші розробники також не приєдналися до вашої компанії, очікуючи, що їм колись доведеться працювати цілодобово. Оперативні люди, швидше за все, цього очікують.

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

Цикл зворотного зв’язку для НДДКР. Я переходжу від припущення, що ви почнете зі створення операційної групи поряд зі своєю командою досліджень та розробок. Виконання DevOps з першого дня може стати мостом занадто далеко. У цьому випадку важливо, щоб ви переконалися, що у вас є необхідні петлі зворотного зв’язку, щоб поділитися тим, що оперативна група навчилася з вашими науково -дослідними групами. Це буде мати вирішальне значення, якщо ви хочете, щоб будь -які проблеми спричинили виправлення помилок, зміни продукту або оптимізацію. На початку це може бути безкоштовним обідом, оскільки ваші ключові спеціалісти можуть бути залучені до всього, але по мірі зростання вашої організації SAAS все більше людей залучатиметься, і вам знадобиться структуроване вирішення цієї проблеми.

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

Розробка для saas

Головною несподіваною проблемою стало те, що нам довелося змінити мислення наших науково -дослідних груп під час створення нових функцій. Створення програмного забезпечення SAAS – це НЕ просто інший спосіб розгортання та обслуговування системи. Це треба писати інакше!

Багато речей, згаданих раніше, не є одноразовими проектами. Розробка функцій, дизайн, виправлення помилок, усунення несправностей, безпека … до SAAS потрібно підходити по -різному, і це має стати другою природою для ваших розробників. Потрапити туди не буде безкоштовним обідом.

Ось лише кілька тем, до яких, можливо, доведеться звикнути вашим розробникам:

не записувати конфіденційні дані до журналів

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

надання документів для оперативних людей

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

очікування тимчасових збоїв

очікування обмежень ставок у залежностях, що використовуються

врахування впливу на інші команди в організації при впровадженні нових технологій

врахування витрат під час розробки нової функції

…

Висновок

Метою цієї статті було не дати вам вичерпний контрольний список для переходу до SAAS, а дати вам список тем, про які ви, можливо, ще не думали і які вам, можливо, доведеться розглянути. Перехід на SAAS – це складне, але захоплююче і веселе заняття. Опинившись там, ви, можливо, ніколи не захочете повернутися до приміщення 🙂

Атрибуції ліцензії для піктограм: Значок доступності, Значок випуску, Значок мислення, Значок операцій, Значок орендаря, Значок безпеки, Значок налаштування, Ікона хмари, Значок кроків

Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/transitioning-from-on-premise-saas-michael-vanhoutte/.

Michael Vanhoutte люб’язно дозволив нам перекласти і опублікувати цю статтю.