Ця публікація написана у співпраці з Клаудією Чіту та Спиридон Досіс від ACAST.
Заснована в 2014, Acast є провідною незалежною компанією подкастів у світі, яка підносить творців подкастів і рекламодавців подкастів, щоб отримати максимальний досвід прослуховування. Відстоюючи незалежну та відкриту екосистему подкастингу, Acast прагне підживлювати подкастинг інструментами та монетизацією, необхідними для процвітання.
Компанія використовує хмарні сервіси AWS для створення продуктів, керованих даними, і масштабування найкращих інженерних практик. Щоб забезпечити стабільну платформу даних на етапах зростання та прибутковості, їхні технічні команди прийняли децентралізовану архітектура сітки даних.
У цій публікації ми обговорюємо, як Acast подолав проблему пов’язаних залежностей між командами, які працюють з даними в масштабі, використовуючи концепцію сітки даних.
Проблема
Завдяки прискореному зростанню та розширенню компанія Acast зіткнулася з проблемою, яка резонує у всьому світі. Acast виявив різноманітні бізнес-підрозділи та величезну кількість даних, створених у всій організації. Існуюча монолітна та централізована архітектура намагалася задовольнити зростаючі потреби споживачів даних. Інженерам з обробки даних ставало дедалі складніше підтримувати та масштабувати інфраструктуру даних, що призводило до доступу до даних, їх розмежування та неефективності керування даними. Ключовою метою було покращити наскрізний досвід користувача, починаючи з потреб бізнесу.
Acast потрібно було вирішити ці проблеми, щоб досягти операційного масштабу, тобто глобальної максимальної кількості людей, які можуть самостійно працювати та забезпечувати цінність. У цьому випадку Acast намагався впоратися з проблемою цієї монолітної структури та високого часу для оцінки для команд продуктів, технічних команд, кінцевих споживачів. Варто зазначити, що вони також мають інші команди з продуктів і технологій, включаючи операційні або бізнес-групи, без облікових записів AWS.
У Acast є змінна кількість команд продуктів, які постійно розвиваються шляхом злиття існуючих, поділу, додавання нових людей або просто створення нових команд. За останні 2 роки у них було 10–20 команд по 4–10 осіб кожна. Кожна команда володіє принаймні двома обліковими записами AWS, до 10 облікових записів, залежно від власності. Більшість даних, створених цими обліковими записами, використовуються для цілей бізнес-аналітики (BI) і в Амазонка Афінасотнями бізнес-користувачів щодня.
Рішення, реалізоване Acast, — це сітка даних, розроблена на AWS. Рішення відображає організаційну структуру, а не явне архітектурне рішення. Відповідно до Зворотний маневр Конвея, технологічна архітектура Acast відображає ізоморфізм із бізнес-архітектурою. У цьому випадку бізнес-користувачі отримують змогу швидше отримувати статистичні дані та безпосередньо знати, хто є власниками конкретного домену, завдяки архітектурі сітки даних, що прискорює співпрацю. Це буде детальніше під час обговорення Управління ідентифікацією та доступом AWS (IAM), оскільки одна з ролей призначена для бізнес-групи.
Параметри успішності
Компанії Acast вдалося запустити та масштабувати новий продукт, орієнтований на команду та домен, а також відповідну інфраструктуру та налаштування, що призвело до менших труднощів під час збору аналітичних даних і задоволених користувачів і споживачів.
Успіх впровадження означав оцінку різних аспектів інфраструктури даних, управління даними та бізнес-результатів. Вони класифікували показники та показники за такими категоріями:
- Використання даних – Чітке розуміння того, хто споживає яке джерело даних, матеріалізується за допомогою відображення споживачів і виробників. Дискусії з користувачами показали, що вони були щасливіші отримати швидший доступ до даних у простіший спосіб, більш структуровану організацію даних і чітке відображення того, хто є виробником. Було досягнуто значного прогресу в розвитку культури, орієнтованої на дані (грамотність даних, обмін даними та співпраця між бізнес-підрозділами).
- Управління даними – Завдяки об’єкту рівня обслуговування, який вказує, коли джерела даних доступні (серед інших деталей), команди знають, кого сповістити, і можуть зробити це за коротший час, якщо дані надходять із запізненням або інші проблеми з даними. Завдяки ролі розпорядника даних було зміцнено право власності.
- Продуктивність команди даних – Ретроспективи інженерів Acast виявили, що їхні команди цінують самостійність у прийнятті рішень щодо своїх доменів даних.
- Ефективність витрат і ресурсів – Це область, де Acast спостерігав зменшення дублювання даних і, отже, зниження витрат (у деяких облікових записах видалення копії даних на 100%) завдяки зчитуванню даних між обліковими записами з одночасним увімкненням масштабування.
Огляд сітки даних
Сітка даних — це соціотехнічний підхід до побудови децентралізованої архітектури даних за допомогою доменно-орієнтованого дизайну самообслуговування (з точки зору розробки програмного забезпечення), який запозичив теорію доменно-керованого дизайну Еріка Еванса та Мануеля Пейса та Метью Скелтона. теорія командних топологій. Важливо встановити контекст, щоб зрозуміти, що таке сітка даних, оскільки вона закладає основу для технічних деталей, які слідують, і може допомогти вам зрозуміти, як концепції, розглянуті в цій публікації, вписуються в ширшу структуру сіті даних.
Щоб нагадати, перш ніж занурюватися глибше в реалізацію Acast, концепція сітки даних базується на таких принципах:
- Він керується доменом, на відміну від конвеєрів як першокласної проблеми
- Він обслуговує дані як продукт
- Це хороший продукт, який захоплює користувачів (дані заслуговують довіри, документація доступна, і її легко використовувати)
- Він пропонує об’єднане обчислювальне керування та децентралізоване володіння — самообслуговувану платформу даних
Архітектура, керована доменом
Згідно з підходом Acast до володіння операційними та аналітичними наборами даних, команди структуровані відповідно до домену, зчитування даних безпосередньо від виробника через API або програмним шляхом із сховища Amazon S3 або використання Athena як механізму запитів SQL. Деякі приклади доменів Acast представлені на наступному малюнку.
Як показано на попередньому малюнку, деякі домени слабко пов’язані з операційними або аналітичними кінцевими точками інших доменів із іншим правом власності. Інші можуть мати сильнішу залежність, що очікується, для бізнесу (деякі подкастери можуть також бути рекламодавцями, створюючи спонсорські креативи та запускаючи кампанії для власних шоу, або транслюючи рекламу за допомогою програмного забезпечення Acast як послуги).
Дані як продукт
Розгляд даних як продукту передбачає три ключові компоненти: самі дані, метадані та відповідний код та інфраструктуру. У цьому підході групи, відповідальні за створення даних, називаються виробники. Ці команди виробників володіють глибокими знаннями про своїх споживачів, розуміючи, як використовується їхній продукт даних. Будь-які зміни, заплановані виробниками даних, заздалегідь повідомляються всім споживачам. Це проактивне сповіщення гарантує, що подальші процеси не будуть порушені. Надаючи споживачам попереднє повідомлення, вони мають достатньо часу, щоб підготуватися до майбутніх змін і адаптуватися до них, зберігаючи плавний і безперебійний робочий процес. Виробники паралельно запускають нову версію початкового набору даних, повідомляють споживачів окремо та обговорюють з ними необхідні часові рамки для початку споживання нової версії. Коли всі споживачі використовують нову версію, виробники роблять початкову версію недоступною.
Схеми даних виводяться із загального узгодженого формату для обміну файлами між командами, яким є Parquet у випадку Acast. Даними можна ділитися у файлах, пакетних або потокових подіях тощо. Кожна команда має власний обліковий запис AWS, який діє як незалежний і автономний суб’єкт із власною інфраструктурою. Для оркестровки вони використовують Набір хмарних розробок AWS (AWS CDK) для інфраструктури як код (IaC) і Клей AWS Каталоги даних для керування метаданими. Користувачі також можуть надсилати запити виробникам щодо покращення способу представлення даних або збагачення даних новими точками даних для створення вищої цінності для бізнесу.
Оскільки кожна команда володіє обліковим записом AWS і ідентифікатором каталогу даних від Athena, це легко побачити через лінзи розподіленого озера даних на Amazon S3 із загальним каталогом, що відображає всі каталоги з усіх облікових записів.
Водночас кожна команда також може зіставляти інші каталоги зі своїм обліковим записом і використовувати власні дані, які вони створюють разом із даними з інших облікових записів. Якщо це не конфіденційні дані, до них можна отримати доступ програмно або з Консоль управління AWS у спосіб самообслуговування, не залежачи від інженерів інфраструктури даних. Це незалежний від домену спільний спосіб самообслуговування даних. Відкриття товару відбувається через реєстрацію в каталозі. Використовуючи лише кілька стандартів, узгоджених і прийнятих у всій компанії, з метою взаємодії, Acast усунув фрагментарні силоси та проблеми з обміном даними або споживанням даних, що не залежать від домену.
За допомогою цього принципу команди отримують впевненість, що дані безпечні, надійні та точні, а відповідні засоби контролю доступу керуються на кожному рівні домену. Крім того, на центральному обліковому записі визначаються ролі для різних типів дозволів і доступу, використання Центр ідентифікації AWS IAM дозволи. Усі набори даних можна знайти в єдиному центральному обліковому записі. На наступному малюнку показано, як це інструментовано, де дві ролі IAM беруть на себе два типи груп користувачів (споживачів): одна має доступ до обмеженого набору даних, що є даними з обмеженим доступом, і інша, яка має доступ до необмежених даних. Існує також спосіб взяти на себе будь-яку з цих ролей для облікових записів служби, таких як ті, які використовуються завданнями обробки даних у Керовані робочі процеси Amazon для Apache Airflow (Amazon MWAA), наприклад.
Як Acast вирішив для високого вирівнювання та слабко пов’язаної архітектури
На наступній діаграмі показано концептуальну архітектуру того, як команди Acast організовують дані та співпрацюють одна з одною.
Acast використовував Добре архітектурна структура для центрального облікового запису, щоб покращити практику виконання аналітичних навантажень у хмарі. Завдяки лінзам інструменту Acast вдалося покращити моніторинг, оптимізація витрат, продуктивність і безпека. Це допомогло їм зрозуміти сфери, де вони можуть покращити своє робоче навантаження та як вирішувати типові проблеми за допомогою автоматизованих рішень, а також як вимірювати успіх, визначаючи KPI. Це заощадило їм час, щоб отримати знання, які інакше знадобилося б більше часу. Спірідон Досіс, спеціаліст з інформаційної безпеки Acast, ділиться: «Ми раді, що AWS завжди попереду, випускаючи інструменти, які дозволяють конфігурувати, оцінювати та переглядати налаштування кількох облікових записів. Це великий плюс для нас, ми працюємо в децентралізованій організації». Спірідон також додає: «Дуже важливою концепцією, яку ми цінуємо, є параметри безпеки AWS за замовчуванням (наприклад, стандартне шифрування для сегментів S3)».
На діаграмі архітектури ми бачимо, що кожна команда може бути виробником даних, за винятком команди, яка володіє центральним обліковим записом, який служить центральною платформою даних, моделюючи логіку з кількох доменів, щоб намалювати повну картину бізнесу. Усі інші команди можуть бути виробниками або споживачами даних. Вони можуть підключатися до центрального облікового запису та відкривати набори даних за допомогою каталогу AWS Glue Data Catalog між обліковими записами, аналізувати їх у редакторі запитів Athena або за допомогою блокнотів Athena або відображати каталог у власному обліковому записі AWS. Доступ до центрального каталогу Athena реалізовано за допомогою IAM Identity Center з ролями для відкритих даних і обмеженого доступу до даних.
Для неконфіденційних даних (відкритих даних) Acast використовує шаблон, де набори даних за замовчуванням відкриті для читання всією організацією, використовуючи умову для надання параметра ідентифікатора, призначеного організацією, як показано в наступному фрагменті коду:
Під час обробки конфіденційних даних, як-от фінансів, команди використовують модель спільного керування даними. Розпорядник даних працює з запитувачем, щоб оцінити обґрунтування доступу для запланованого використання. Разом вони визначають відповідні методи доступу для задоволення потреб, зберігаючи безпеку. Це може включати ролі IAM, облікові записи служб або певні служби AWS. Цей підхід дозволяє бізнес-користувачам за межами технічної організації (це означає, що вони не мають облікового запису AWS) самостійно отримувати доступ і аналізувати потрібну їм інформацію. Надаючи доступ через політики IAM до ресурсів AWS Glue і сегментів S3, Acast забезпечує можливості самообслуговування, водночас керуючи делікатними даними через перевірку людьми. Роль розпорядника даних була цінною для розуміння випадків використання, оцінки ризиків безпеці та, зрештою, полегшення доступу, що прискорює бізнес завдяки аналітичним уявленням.
Для випадку використання Acast не були потрібні детальні елементи керування доступом на рівні рядків або стовпців, тому цього підходу було достатньо. Однак іншим організаціям може знадобитися більш детальне керування полями конфіденційних даних. У таких випадках такі рішення, як Формування озера AWS може реалізувати необхідні дозволи, водночас забезпечуючи самообслуговувану модель доступу до даних. Для отримання додаткової інформації див Створіть архітектуру сітки даних за допомогою AWS Lake Formation і AWS Glue.
У той же час команди можуть читати дані інших виробників безпосередньо, з Amazon S3 або через API, зберігаючи залежність на мінімумі, що підвищує швидкість розробки та доставки. Таким чином, обліковий запис може бути виробником і споживачем паралельно. Кожна команда є автономною та відповідає за свій власний стек технологій.
Додаткові навчання
Чого навчився Acast? Досі ми обговорювали, що архітектурний дизайн є ефектом організаційної структури. Оскільки технічна організація складається з кількох міжфункціональних команд, і легко створити нову команду, дотримуючись загальних принципів сітки даних, Acast зрозумів, що це не завжди проходить гладко. Щоб налаштувати абсолютно новий обліковий запис в AWS, команди проходять ту саму подорож, але дещо іншу, враховуючи їхні власні особливості.
Це може спричинити певні тертя, і важко змусити всі команди, які створюють дані, досягти високої зрілості виробників даних. Це можна пояснити різними компетенціями даних у цих міжфункціональних командах і тим, що вони не є спеціалізованими групами даних.
Впровадивши децентралізоване рішення, Acast ефективно впоралася з проблемою масштабованості, адаптувавши свої команди відповідно до мінливих потреб бізнесу. Такий підхід забезпечує високий рівень розв’язки та вирівнювання. Крім того, вони зміцнили право власності, значно скоротивши час, необхідний для виявлення та вирішення проблем, оскільки вихідне джерело є добре відомим і легко доступним за допомогою певних SLA. Обсяг запитів на підтримку даних зменшився більш ніж на 50%, оскільки бізнес-користувачі мають змогу швидше отримувати інформацію. Примітно, що вони успішно усунули десятки терабайт надлишкового сховища, яке раніше було скопійовано виключно для виконання низхідних запитів. Це досягнення стало можливим завдяки впровадженню зчитування між обліковими записами, що призвело до усунення пов’язаних витрат на розробку та обслуговування цих конвеєрів.
Висновок
Acast використовував закон зворотного маневру Конвея та використовував служби AWS, де кожна багатофункціональна команда продуктів має власний обліковий запис AWS, щоб побудувати архітектуру сітки даних, яка забезпечує масштабованість, високий рівень власності та споживання даних для самообслуговування. Це добре спрацювало для компанії щодо підходу до володіння даними та операцій, щоб відповідати їхнім інженерним принципам, у результаті чого сітка даних була результатом, а не навмисним наміром. Для інших організацій бажана сітка даних може виглядати інакше, і підхід може мати інші знання.
На закінчення, a сучасна архітектура даних на AWS дозволяє ефективно створювати продукти даних та інфраструктуру сітки даних за низькими витратами без шкоди для продуктивності.
Нижче наведено кілька прикладів сервісів AWS, які можна використовувати для розробки бажаної сітки даних на AWS:
Про авторів
Клаудія Чіту є стратегом даних і впливовим лідером у сфері аналітики. Зосереджена на узгодженні ініціатив щодо даних із загальними стратегічними цілями організації, вона використовує дані як керівну силу для довгострокового планування та сталого зростання.
Спиридон Досіс є спеціалістом з інформаційної безпеки в Acast. Spyridon підтримує організацію в розробці, впровадженні та експлуатації її послуг у безпечний спосіб, захищаючи дані компанії та користувачів.
Срікант Дас є архітектором рішень Acceleration Lab в Amazon Web Services. Він має понад 13 років досвіду в аналітиці великих даних та розробці даних, де йому подобається створювати надійні, масштабовані та ефективні рішення. Поза роботою він любить подорожувати та публікувати свій досвід у соціальних мережах.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
- PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
- ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
- PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
- джерело: https://aws.amazon.com/blogs/big-data/design-a-data-mesh-on-aws-that-reflects-the-envisioned-organization/
- : має
- :є
- : ні
- :де
- $UP
- 10
- 100
- 120
- 13
- 2014
- 2020
- a
- Здатний
- МЕНЮ
- прискорений
- прискорюється
- прискорення
- доступ
- Доступ до даних
- доступний
- доступною
- рахунки
- підзвітний
- Рахунки
- точний
- досягнення
- через
- діючий
- дію
- пристосовувати
- додати
- адреса
- адресований
- Додає
- прийнята
- оголошення
- просування
- Рекламодавцям
- вирішено
- попереду
- Цілі
- вирівнювати
- вирівнювання
- вирівнювання
- ВСІ
- дозволяти
- дозволяє
- по
- Також
- завжди
- Amazon
- Amazon Web Services
- Серед
- серед
- кількість
- an
- Аналітичний
- аналітика
- аналізувати
- та
- та інфраструктури
- будь-який
- Apache
- API
- цінувати
- підхід
- відповідний
- архітектурний
- архітектура
- ЕСТЬ
- ПЛОЩА
- області
- AS
- аспекти
- Оцінювання
- оцінка
- асоційований
- припустити
- передбачається
- гарантія
- At
- Автоматизований
- автономний
- Автономія
- доступний
- AWS
- Клей AWS
- Формування озера AWS
- заснований
- BE
- оскільки
- було
- перед тим
- буття
- КРАЩЕ
- передового досвіду
- Краще
- між
- Великий
- Великий даних
- Блоги
- Bootstrap
- ширше
- будувати
- Створюємо
- бізнес
- бізнес-аналітика
- але
- by
- Кампанії
- CAN
- можливості
- випадок
- випадків
- каталог
- каталоги
- категорії
- Центр
- центральний
- централізована
- певний
- виклик
- проблеми
- складні
- виступаючи
- Зміни
- класифікований
- ясно
- хмара
- хмарні сервіси
- код
- співробітництво
- співробітництво
- спільний
- майбутній
- загальний
- зазвичай
- спілкувалися
- компанія
- Компоненти
- компрометуючі
- обчислювальна
- концепція
- поняття
- концептуальний
- укладає
- стан
- конфігурація
- З'єднуватися
- беручи до уваги
- Складається
- складається
- будувати
- споживати
- споживач
- Споживачі
- споживання
- контекст
- постійно
- управління
- Відповідний
- Коштувати
- зниження витрат
- витрати
- може
- з'єднаний
- створювати
- створення
- креативні
- Творці
- міжфункціональні команди
- культура
- дані
- доступ до даних
- Analytics даних
- інфраструктура даних
- Озеро даних
- управління даними
- Платформа даних
- точки даних
- обробка даних
- обмін даними
- керовані даними
- набори даних
- день
- Децентралізований
- рішення
- рішення
- присвячених
- глибше
- дефолт
- за замовчуванням
- певний
- визначаючи
- доставляти
- доставка
- запити
- залежно
- Залежність
- залежний
- Залежно
- дизайн
- проектування
- бажаний
- докладно
- деталі
- Визначати
- розробка
- DID
- різний
- важкий
- безпосередньо
- відкрити
- відкриття
- обговорювати
- обговорювалися
- обговорення
- дисплеїв
- розподілений
- Різне
- дайвінг
- do
- документація
- Ні
- домен
- домени
- Не знаю
- керований
- e
- кожен
- легко
- екосистема
- редактор
- ефект
- фактично
- ефективний
- продуктивно
- піднесення
- усувається
- працевлаштований
- наймаючи
- працює
- уповноважений
- включіть
- включений
- дозволяє
- дозволяє
- шифрування
- кінець
- кінець в кінець
- кінцеві точки
- двигун
- Машинобудування
- Інженери
- підвищувати
- Підсилює
- збагачувати
- забезпечувати
- гарантує
- Весь
- суб'єкта
- передбачуваний
- Еріком
- встановити
- Ефір (ETH)
- оцінювати
- Події
- Кожен
- кожен день
- еволюціонує
- приклад
- Приклади
- Крім
- обмін
- існуючий
- розширення
- очікуваний
- досвід
- Досліди
- пояснені
- сприяння
- далеко
- швидше
- кілька
- Поля
- Рисунок
- Файли
- фінансові
- знайти
- виявлення
- відповідати
- увагу
- стежити
- після
- для
- Примусово
- формат
- освіта
- знайдений
- фрагментарно
- Рамки
- тертя
- від
- Паливо
- Виконати
- Повний
- повністю
- далі
- Крім того
- Отримувати
- збір
- генерується
- породжує
- отримати
- Глобальний
- Глобально
- Go
- Цілі
- добре
- управління
- управління
- Надання
- зернистий
- Group
- Групи
- Зростання
- Зростання
- керівництво
- було
- Обробка
- відбувається
- щасливіше
- щасливий
- Мати
- має
- he
- допомога
- допоміг
- Високий
- вище
- його
- Як
- How To
- Однак
- HTTP
- HTTPS
- людина
- Сотні
- МАК
- IAM
- ID
- ідентифікувати
- Особистість
- ілюструє
- здійснювати
- реалізація
- реалізовані
- реалізації
- важливо
- удосконалювати
- in
- поглиблений
- включати
- У тому числі
- все більше і більше
- незалежний
- самостійно
- індикатори
- Індивідуально
- неефективність
- Впливовий
- інформація
- інформаційна безпека
- Інфраструктура
- початковий
- ініціативи
- Запити
- розуміння
- Інтелект
- призначених
- намір
- Взаємодія
- в
- питання
- IT
- ЙОГО
- сам
- Джобс
- подорож
- JPG
- зберігання
- ключ
- Знати
- знання
- відомий
- lab
- озеро
- останній
- Пізно
- закон
- лідер
- провідний
- УЧИТЬСЯ
- вчений
- найменш
- лінзи
- менше
- рівень
- як
- обмеженою
- Прослуховування
- грамотність
- логіка
- довгостроковий
- довше
- подивитися
- серія
- низький
- made
- підтримувати
- збереження
- обслуговування
- Більшість
- зробити
- вдалося
- управління
- манера
- карта
- відображення
- Матвій
- зрілість
- максимальний
- Може..
- сенс
- засоби
- означав
- вимір
- Медіа
- Зустрічатися
- злиття
- сітці
- метадані
- методика
- Метрика
- може бути
- мінімальний
- модель
- моделювання
- монетизація
- моніторинг
- більше
- Більше того
- множинний
- необхідно
- Необхідність
- необхідний
- потреби
- Нові
- особливо
- ноутбуки
- Зверніть увагу..
- сповіщення
- номер
- об'єкт
- мета
- спостерігається
- of
- Пропозиції
- Офіцер
- on
- ONE
- ті,
- тільки
- відкрити
- відкриті дані
- працювати
- операційний
- оперативний
- операції
- протистояли
- or
- оркестровка
- порядок
- організація
- організаційної
- організації
- організація
- Інше
- інші
- інакше
- Результати
- поза
- над
- загальний
- власний
- Власники
- власність
- володіння
- володіє
- фарбувати
- Паралельні
- параметр
- Люди
- для
- продуктивність
- Дозволи
- перспектива
- фаз
- картина
- місце
- запланований
- планування
- платформа
- plato
- Інформація про дані Платона
- PlatoData
- плюс
- Подкаст
- Подкастинг
- точок
- Політика
- володіти
- це можливо
- пошта
- практика
- практики
- попередній
- Готувати
- представлений
- раніше
- Головний
- принцип
- Принципи
- Проактивний
- процеси
- обробка
- виробляти
- Вироблений
- виробник
- Виробники
- виробництво
- Product
- Продукти
- професійний
- рентабельність
- прогрес
- захищає
- забезпечувати
- забезпечує
- забезпечення
- мета
- цілей
- підвищення
- швидше
- досягати
- Читати
- легко
- читання
- Короткий огляд
- зниження
- скорочення
- послатися
- називають
- Відображає
- про
- Реєстрація
- випуску
- надійний
- видалення
- видалення
- запитів
- вимагати
- рішення
- резонує
- ресурс
- ресурси
- відповідальний
- обмежений
- в результаті
- огляд
- ризики
- Роль
- ролі
- прогін
- біг
- то ж
- зберігаються
- масштабованість
- масштабовані
- шкала
- Масштабування
- плавно
- безпечний
- безпеку
- ризики для безпеки
- побачити
- бачив
- Самообслуговування
- чутливий
- служить
- обслуговування
- Послуги
- комплект
- набори
- установка
- Поділитись
- загальні
- акції
- поділ
- вона
- показав
- показаний
- Шоу
- істотно
- силоси
- простий
- просто
- один
- трохи відрізняється
- згладити
- уривок
- So
- так далеко
- соціальна
- соціальні медіа
- Софтвер
- програмне забезпечення як послуга
- розробка програмного забезпечення
- виключно
- рішення
- Рішення
- вирішити
- деякі
- Source
- Джерела
- Простір
- конкретний
- зазначений
- спонсорство
- SQL
- стек
- Стажування
- стандартів
- старт
- Починаючи
- Заява
- про те,
- Як і раніше
- зберігання
- просто
- Стратегічний
- Стратег
- потік
- посилений
- більш сильний
- структура
- структурований
- Бореться
- успіх
- Успішно
- такі
- достатній
- підтримка
- Опори
- сталого
- Стале зростання
- снасті
- взяття
- команда
- команди
- технології
- технічний
- Технологія
- шаблон
- тензор
- ніж
- Що
- Команда
- інформація
- їх
- Їх
- теорія
- Там.
- отже
- Ці
- вони
- це
- ті
- три
- Процвітати
- через
- час
- терміни
- до
- разом
- інструмент
- інструменти
- топ
- укладання угод
- Подорож
- намагався
- заслуговуючий довіри
- два
- Типи
- кінцевий
- Зрештою
- розуміти
- розуміння
- безперебійний
- одиниць
- Майбутні
- на
- us
- використання
- використання випадку
- використовуваний
- користувач
- User Experience
- користувачі
- використовує
- використання
- використовувати
- Цінний
- значення
- змінна
- різний
- величезний
- VeloCity
- версія
- дуже
- через
- обсяг
- було
- шлях..
- we
- Web
- веб-сервіси
- ДОБРЕ
- були
- Що
- коли
- який
- в той час як
- ВООЗ
- кого
- волі
- з
- без
- Work
- робочий
- Робочі процеси
- робочий
- працює
- світі
- вартість
- б
- письмовий
- років
- ви
- вашу
- зефірнет