DevOps у хмарі: найкращі практики та підводні камені для хмарного розгортання та розробки від Copado

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

Щоб краще зрозуміти, як компанії можуть використовувати DevOps для великомасштабного розгортання хмари, я розмовляв із Девідом Бруксом, віце-президентом із продуктів у Копадо, який надає платформу DevOps для Відділ продажів Платформа. До цього Девід був початковим менеджером із продуктів компанії Salesforce AppExchange. Відео мого інтерв’ю з Бруксом розміщено у верхній частині цієї статті, а стенограма – нижче.

також: Спеціальний звіт: на шляху революції DevOps (безкоштовний PDF) (з дочірнього сайту ZDNet TechRepublic)

Сучасні хмарні обчислювальні системи є масовими й поширені по всьому світу

Білл Детвілер: Що робить масштабне розгортання хмарних служб іншим і потенційно складнішим, ніж традиційні локальні системи та програмне забезпечення?

Девід Брукс: Ну, перше, що я б сказав, це масштаб. The хмарні системи сьогодні масові. Вони по всьому світу. Коли ми потрапили в цю гру, ми побачили реалізації, які були більшими, ніж ми очікували. Ви повинні пам’ятати, що це користувачі по всьому світу, це не просто одна організація, розташована в Північній Америці, можливо, з двома містами та парою сотень користувачів або навіть кількома тисячами користувачів. Це десятки тисяч користувачів по всьому світу в різних часових поясах, 24 години на добу. Над деякими з цих реалізацій сонце ніколи не заходить. У цьому задіяні сотні середовищ. Швидкість з хмарою. У той час, коли ви випускали програму ERP, ваші облікові системи змінювалися раз на рік, раз на пару років. Скільки разів ви виконуєте оновлення SAP? Не дуже часто, якщо ви можете допомогти.

Але з, з CRM системи, з продажу, маркетингу та обслуговування, ви робите випуски пару разів на місяць, тому що ваші процеси налаштовані. А коли мова заходить про системи та взаємодію, коли ви спілкуєтеся зі своїми клієнтами та партнерами, особливо з IoT і деякі системи, які ви інтегруєте сьогодні, ви робите кілька випусків на день. Тож швидкість випуску з хмарними системами просто набагато швидша, ніж з тим, з чим вам доводилося мати справу в минулому з деякими з цих локальних систем. І рівень складності, хмарна платформа вже сама по собі складна, але ви також говорите про інтеграцію. У вас є інтеграція з багатьма іншими системами. Уявіть, що ваша система надає карту. Ну, ви не робите карти, ви інтегруєтеся з картами Google. І якщо ви робите IoT, ви збираєтеся відстежувати пристрої за допомогою інших видів послуг. Ви можете принести погоду. Отже, ви підключаєтеся до метеослужби, а потім до зовнішніх даних, до яких ви підключаєтеся.

Таким чином, усі ці зовнішні системи ефективно переплітаються. Вони заплутуються, і вони ускладнюють справжню ізоляцію системи, над якою ви працюєте, тому що вам потрібно хвилюватися про всі інші речі. А безпека, безпека тільки через рани. Я не знаю, чи бачили ви останнім часом, нещодавно ви бачили a Marriott оштрафували на 123 мільйони доларів за недотримання GDPR. Ймовірно, це сталося через якийсь невеликий випуск, який вони випадково надали комусь дані. Авіакомпанію British Airways оштрафували на 230 мільйонів доларів за те, що вони поставили під загрозу дані 500 000 клієнтів. Тож DevOps — це не просто випустити невелику функцію тут і там, а потім покінчити з нею. Ціна неправильного виконання може бути насправді дуже, дуже важливою і дуже, дуже великою.

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

Детальніше: Як Salesforce правильно влаштував конференцію розробників, а Microsoft, Apple, Facebook і Google заблукали

Як використовувати DevOps для корпоративних хмарних проектів

Білл Детвілер: Як DevOps може допомогти компаніям впоратися зі складними хмарними розгортаннями та уникнути простоїв?

Девід Брукс: Ну, це починається з процесу. У нас було кілька консультаційних рад клієнтів у Бостоні та Дюссельдорфі, куди ми заходили й запитували наших клієнтів, що ми можемо зробити, щоб покращити нашу платформу? І ми отримали дивовижну відповідь. Ми очікували чогось від інструментів і процесів, якими ми керуємо, і ми отримали допомогу в тому, щоб зрозуміти, як покращити наш процес, наш процес доставки, нашу стратегію. Отже, ми з’ясували, що підвищення вашої швидкості та збільшення часу для досягнення цінності на ринку – це певним чином більше про те, щоб ваша команда була дисциплінованою, що вони мають необхідну інформацію, що вони мають необхідну підготовку та що у вас є набір інструментів або платформа, як-от Copado, для фактичної роботи з вами та вашими процес.

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

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

Найкращі практики DevOps для хмарної розробки та розгортання

Білл Детвілер: Яких передових практик можуть дотримуватися компанії, включаючи DevOps у свою хмарну стратегію?

Девід Брукс: Так, перше, що слід визнати, це те, що компанії знаходяться на різних рівнях зрілості та різних рівнях прийняття. Отже, компанії знаходяться на різних рівнях, але люди в цих компаніях також знаходяться на різних рівнях, і усвідомлення цього дозволяє вам почати зосереджуватися на своїх найкращих практиках. І ми придумали стратегію, модель, яку ми назвали Pathfinder, і в моделі Pathfinder ми намагалися спростити її до такої міри, щоб говорити про п’ять рівнів зрілості.

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

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

Тож моя перша рекомендація — сісти й подивитись на свій процес, зрозуміти різні етапи та зрозуміти, що ти і будьте чесними з собою щодо оцінки, яку б ви поставили собі за цей процес, і з’ясуйте, як отримати краще. Кожен перебуває на різному рівні, тому є чудовий приклад. Ми працювали з MassMutual пару років тому, і це був чудовий приклад. Вони дуже розчарувалися в Salesforce на початку роботи на платформі. У них було лише близько 20 чи 30 розробників, які працювали над Salesforce, і це була для них нова платформа DevOps, тому залучення Copado було це був цікавий процес для них, тому що окрім впровадження нового набору інструментів і нової платформи DevOps, вони мали запровадити нову процес, і їм довелося повторити його, і їм потрібно було реально подивитися, що вони роблять у кожному з цих сегментів з найкращим практики. Як вони використовували свої гнучкі інструменти?

ПОБАЧИТИ: Опис посади: DevOps інженер (з дочірнього сайту ZDNet TechRepublic)

І якщо ви використовуєте, ще одна дуже важлива річ — це використання системи контролю версій як джерела правди. Ми виявили, що багато компаній у середовищі Salesforce використовують саму платформу як джерело правди, а ви просто не можете цього робити. Вам потрібно a система контролю версій, наприклад Git зробити це. Отже, якщо ви подивіться на передній кінець вашого процесу DevOps і на те, як ви використовуєте свою систему контролю версій, навіть такі речі, як те, яку стратегію розгалуження я використовую? Я не хочу вникати в бур’яни та в гайки та болти, але те, як ви насправді формуєте гілки у вашій системі контролю версій мають рівні зрілості та рівні можливостей покращення для вас. Тож коли ми працювали з MassMutual, ми пішли з ними та подивилися на їхній процес на всіх цих різних етапах і допомогли їм зрозуміти, де вони знаходяться та де вони можуть удосконалюватись і куди вони могли б просуватися по сходах успіху з кожним із них, і цілісне виконання, а також окремі етапи призводять до можливості просуватися все вище і вище драбина. Отже, це справа дивитися зверху вниз, але це також питання знизу вгору, намагаючись покращити кожен із цих процесів.

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

Я маю на увазі, що в 2002, 2003 роках я допоміг встановити Salesforce у компанії, і я був адміністратором. Я керував командою адміністраторів цієї компанії. І я не планував бути адміністратором. Чесно кажучи, мене змусили прийняти цю роль, тому що я був найкращим хлопцем для цієї роботи на той момент. Але ці випадкові адміністратори з усього світу зараз на Salesforce потрапляють туди, і вони йдуть, я не знаю, що таке DevOps. Все, що я знаю, це те, що я можу перейти до налаштування, я можу внести ці зміни та зберегти їх, і моя робота зроблена. Але насправді найкраще зібрати цих адміністраторів на одній сторінці з розробниками. І що це означає? Це означає, що люди думають, що це означає, що адміністратор повинен знати, як користуватися Git, мати гнучкі інструменти, такі як Jira, і вміти працювати з історіями користувачів. А реальність така, що вони цього не роблять.

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

Помилок, яких слід уникати з DevOps і корпоративними хмарними проектами

Білл Детвілер: Яких найбільших помилок люди роблять, коли починають великий проект розгортання та оновлення хмари?

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

Інша найбільша проблема або найбільша помилка полягає в тому, що люди намагаються зайти туди і змінити все відразу. Мені здається, єдине, чого нас навчив agile, — це невеликі зміни, чи не так? Якщо ви поглянете назад на той фільм «Контакт», де він говорить про невеликі зміни, Еллі. Внесіть невеликі зміни на свій радіоциферблат, щоб ви могли набрати його та розпочати роботу, щоб щось працювало та досягали прогресу. І це як піднятися на пагорб. Ви повинні піднятися на той перший пагорб, а потім вам потрібно зробити подих, розвернутися і насолодитися тим, що ви потрапили на плато, і не намагайтеся виконувати всі процеси одночасно.

ПОБАЧИТИ: Як iRobot використовував науку про дані, хмару та DevOps для розробки своїх розумних домашніх роботів наступного покоління (обкладинка у форматі PDF) (з дочірнього сайту ZDNet TechRepublic)

Тож, наприклад, коли ми встановлюємо Copado у наших найбільших клієнтів, ми кажемо: чудово. Давайте зробимо крок назад і давайте з’ясуємо, як ми збираємося спочатку виконати частину управління змінами, частину управління випусками. Давайте підключимося до вашої існуючої гнучкої системи. Давайте підключимося до вашого існуючого GitRepo і зробимо це спочатку. А потім, як тільки це буде на місці, перейдіть до перевірок. Ви проводите тестування на селен? Ви проводите статичний аналіз коду? Ви використовуєте інструмент відповідності? Що у вас є зовнішні сценарії Jenkins або team city, які ви запускаєте для цього? Я маю на увазі, давайте почнемо це робити. Тому найбільшою помилкою було б намагатися зробити все і відразу. І найбільша порада, яку я можу дати, — не намагайтеся цього робити. Просто йдіть крок за кроком і співпрацюйте, повторюйте і відкусуйте невеликий шматочок і освоїте це, а потім переходьте до наступного, тому що робота не закінчена в кінці реалізації. Робота тільки починається, і вся справа в безперервних інноваціях як у вашому процесі, так і у вашій компанії.

ПОНЕДІЛОВИЙ РАНОК ZDNET

Monday Morning Opener — це наш вступний залп тижня в галузі технологій. Оскільки ми керуємо глобальним сайтом, ця редакційна стаття публікується в понеділок о 8 ранку за східним часом у Сіднеї, Австралія, тобто о 6 вечора за східним часом у США. Він написаний членом глобальної редакційної колегії ZDNet, яка складається з наших провідних редакторів з Азії, Австралії, Європи та Північної Америки.

РАНІШЕ У ПОНЕДІЛОК РАНОК ВІДКРИТТЯ:

• Windows 7 проти Windows 10: наступний великий виклик
  
• Ласкаво просимо на Amazon Prime Day 2019: ось стратегія божевілля електронної комерції
  
• Що якби Microsoft винайшла Android?
• 5G не готовий до прайму в 2019 році
• Чому досвід співробітників, програмне забезпечення для залучення може бути гарячим місцем
• Як Salesforce правильно влаштував конференцію розробників, а Microsoft, Apple, Facebook і Google заблукали
• Як інформаційна панель екологічного контексту коледжу підкреслює прозорість алгоритмів проти питання пояснюваності
  
• Війни за шифрування повертаються, але цього разу все по-іншому
  
• Переможець у війні з Huawei – Samsung
  
• Хмарні, корпоративні технології рішуче виходять з ери нульової суми та починають свято кохання