18 твердих «ЗА» та 10 ситуацій, де хмари «не працюють» (переклад статті)

Автор статті – Джо Маккендрік (Joe McKendrick)– відомий англійський дослідник новітніх ІТ-технологій та хмарних обчислень.

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

У своїй новій книзі, Cloudonomics, Joe Weinman (який вважається ідейним лідером розвитку мистецтва і науки хмарної економіки) досліджує багато областей з точку зору хмарних обчислень, пропонуючи переконливі пропозиції цінності хмар. Він дуже ретельно викладає бізнес-кейси та вартість обґрунтувань. Він також вказує 28 бізнес-областей, де хмара має та не має ділової та фінансової цінності (а що дивно, всі ці області йому вдалося класифікувати в термінах, що починаються з літери «C»).

18 областей, де хмарні обчислення мають сенс:

1. Додаткові можливості та компетенції (Complementary capabilities and competencies). Хмара може запропонувати такі можливості, яких у фірми немає. Це може бути інфраструктурний рівень - наприклад, центри обробки даних, програмний рівень - специфічні алгоритми кодування, оптимізовані та доступні тільки через хмару, на різних рівнях - всілякі операції із посилення безпеки. Також сюди можна включити використання різних онлайн-сервісів, пошукових систем, веб-систем, користування інформацією про польоти, зміни в розкладах або даних фондових ринків.
2. Комунікації (Communications). Будь то електронна пошта, відео, спільна робота або що-небудь ще, все це можливо у хмарі. Будь-який вид зв’язку буде більш оптимізований та ефективний саме завдяки хмарній архітектурі. Альтернатива цьому – будівництво прямої фізичної мережі між усіма учасниками. Зрозуміло, що це нереально.
3. Бесіди, зв'язки і співтовариства (Conversations, connections and communities). Хмара може відігравати ключову роль, оскільки вона допомагає виявити товариства, членів цих товариств та підтримувати зв’язки всередині спільнот.
4. Збори, громади і сумісні колекції (Congregations, commons and collections). Хмарні системи можуть забезпечити загальний доступ до ресурсів, а також дозволяють кінцевим користувачам із загальними інтересами зустрічатися і обмінюватися інформацією.
5. Об’єднання (Consolidation). Замість того, що десятки мільйонів людей будуть робити та зберігати копії одного і того ж змісту, копії можуть бути збережені в хмарі, з урахуванням правових і нормативних обмежень.
6. Співпраця, конкуренція і краудсорсінг (виконання якихось функцій колом людей) (Collaboration, competition, and crowdsourcing). Ці три підходи бізнесу мають спиратися на хмарні обчислення, щоб охопити максимальну кількість людей.
7. Торгівля та безготівкові відношення (Commerce and clearing). Фізичні ринки починають витіснятися цифровими ринками, які працюють на хмарних застосунках.
8. Спільне споживання (Collaborative consumption). Хмарна модель підтримує нові системи, засновані на «комунальній економіці та перерозподілі ринків». Хмара грає роль суб'єкта ринку, що з'єднує людей, які мають товари, з людьми, які хочуть їх купити, не гірше реклами.
9. Координація, строк дії, послідовність і контроль (Coordination, currency, consistency, and control). При веденні документів у хмарі можна змінювати документ, скасовувати ці зміни чи редагувати далі. З програмним забезпеченням як послугою будь-яке оновлення ПЗ треба зробити один раз, після чого це оновлення миттєво доступне усім користувачам.
10. Крос-пристрої доступу та синхронізація (Cross-device access and synchronization). Хмара відіграє активну роль у мобільному просторі, що формується, й може допомогти в синхронізації контенту або застосунків декількох пристроїв у одного користувача.
11. Грошові витрати (Cash flow). Для великих, багатих на готівку підприємств вигоди від переміщення частини капітальних витрат в операційні, можливо, й не роблять погоди. Але для безгрошових стартапів, малого та середнього бізнесу та великих підприємств, які намагаються зберегти грошові кошти, економія витрат з хмарами може бути суттєвою.
12. Потужність (Capacity). Потужність є однією з основних переваг використання інфраструктури як послуги. Хмарна потужність може доповнювати існуючі потужності корпоративного центру обробки даних або наявного обладнання.
13. Безперервність (Continuity). Навряд чи хтось буде утримувати другий будинок в якості запасного, на випадок того, що щось трапиться з їх основним. Хмара дозволяє бізнесу мати справжню безперервність та аварійне відновлення, де резервне копіювання даних не потребує обчислювальної потужності.
14. Контрольні пункти (Checkpoints). Так само, як національні кордони захищені, хмара може ефективно фільтрувати все, починаючи від вірусів і спаму до розподілених атак.
15. «Вузькі місця» (Chokepoints). Так само, як авіадиспетчери в аеропортах можуть чітко, майже «упритул», регулювати рейси, що прибувають і відбувають, хмара може робити те саме - регулювання, захист, формування, обмеження та управління потоками даними.
16. Контекст (Context). Основні види діяльності - такі, наприклад, як дизайн продукту - повинен залишатися в межах підприємства, але діяльність по супроводженню основних видів – так званий контекст - може бути легко переміщений у хмару. Мова йде про ті загальні функції бізнесу, які не дають явних конкурентних переваг, - звітність, управління воронкою продаж, система біллінгу тощо.
17. Стрімкість (Celerity). Стрімкість, або швидкість, є важливою перевагою хмари, так як додатки можуть бути встановлені протягом декількох днів, а іноді і годин. Програмне забезпечення як послуга та платформа як сервіс надає можливість значно скоротити час розробки, у той час як інфраструктура як послуга дозволяє уникнути необхідності розпакування обладнання, включення його та перевірки розробленого.
18. Лояльність та досвід споживачів (Customer experience). Скорочення часу поліпшує відношення користувачів/клієнтів. Хмара цьому допомагає кількома способами, в тому числі й підвищеною швидкістю, про яку йшлося вище. Також на це впливає й широке розповсюдження систем. Так само, як наявність Starbucks на кожному розі скорочує час для клієнта, щоб випити чашку кави, так і організація необхідного застосунку «всюди» - на кожному розі – знижує час необхідної взаємодії із застосунком для отримання результату.

І ось 10 випадків, коли хмари не підходять:

1. Постійна вимога (Constant demand). Якщо попит є відносно пласким і передбачуваним, навряд чи є необхідність в переміщенні застосунків. Абсолютно життєздатна стратегія може бути залишена «в будинку».

   Примітки Tucha: можливо, це реально для американського життя, але в Україні замало передбачуваності та стабільності, тому кожній компанії, з оглядом на майбутнє, краще розглядати хмари.

2. Користувальницькі середовища (Custom environments). Окремо розроблені, індивідуальні середовища, які часто є джерелом переваг у бізнесі, – складно повторити у більш простій хмарі.

   Примітки Tucha: звичайно, перенести у Dropbox внутрішній портал компанії навряд чи вдасться, але в Tucha (бо IaaS створено саме для цього) може мігрувати все, окрім, хіба що, офісної кавоварки. :)

3. Класична старина (Classic legacy). І вартість переносу висока, і зусилля по міграції «застарілого» до нової масштабної архітектури та сучасних парадигм програмування будуть потрібні дуже значні, що не зовсім вигідно.

   Примітки Tucha: по-перше, як вже говорилося, використовуючи IaaS, навіть волохатого мамонта можна перенести у хмару, а, крім того, пам’ятаймо, що бізнес, який не сприймає змін, приречений плестися за більш активними та інноваційними конкурентами.

4. Щільні, сильні зв’язки між застосунками (Close coupling of applications). Застарілі застосунки, як правило, тісно пов'язані з існуючою локальною інфраструктурою, зі сховищем або мережами - і таким чином ці зв’язки може бути важко та дорого розірвати.

   Примітки Tucha: у цьому немає потреби – інфраструктура здатна мігрувати до хмари цілком, зі збереженням усіх важливих зв’язків.

5. Постійне отримання, створення і споживання контенту (Constant capture, creation, and consumption of content). Якщо все відбувається на рівні кінцевого користувача, то хмара не зовсім зможе допомогти. Хмара не може робити фіксувати чи відображати контент, це можуть тільки кінцеві пристрої.

   Примітки Tucha: вочевидь, це сильний аргумент, але досить незрозумілий. :)

6. Криптографія (Cryptography). Шифрувати дані треба до того, як їх передавати в хмару. Передавати незашифровані дані в хмару для подальшого шифрування все одно, що відправити в банк п'ятирічну дитину через ліс з паперовим мішком з грошима.

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

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

   Примітки Tucha: це не має значення, коли дані і генеруються, і зберігаються в хмарі.

8. Кеш (Caching). Тимчасове зберігання даних для прискорення доступу було досить добре освоєне в локальних системах, і це можуть намагатися перенести у хмару. Але у хмарі вартість доступу до даних збільшується зі збільшеним їх обсягу.

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

9. Таємниці (Covert). Не ходіть в хмару, якщо у вас є комерційні таємниці або службова інформація, до якої ви не хочете нікого допускати. Якщо хтось турбується про таємний рецепт смаження курки, то краще тримати його вдома.

   Примітки Tucha: «вдома», на жаль, ніхто не застрахований від пожежі, крадія рецептів чи вилучення рецепту повноважними працівниками рецептурного відділу. Тримати важливу інформацію в хмарі безпечніше, треба лише потурбуватися про її захист. Як і будь-де, до речі.

10. Безперервність (Continuity). Хоча безперервність здається природньою у разі використання хмар, зворотне теж вірно. Локальна копія під вашим контролем може допомогти уникнути втрати даних у хмарі, а місцеві можливості обробки можуть забезпечити безперервність обробки цих даних.

    Примітки Tucha: не варто змішувати безперервність та зберігання даних. Навіть якщо зв'язок із хмарою на мить втрачено, дані, що знаходяться на кластері, гарантовано залишаються у безпеці. Чи завжди можна бути так само впевненим у локальних носіях даних?

Оригінал статті англійською мовою: http://www.forbes.com/sites/joemckendrick/2012/09/10/18-solid-justifications-for-cloud-computing-and-10-situations-where-it-doesnt-work/.