Вступ
Завдяки своїм інтересам, і значною мірою завдяки вибору кар’єри, мені дуже пощастило, що я зазвичай працюю з новітніми технологіями більшість часу. Я, хто вперше застосував Docker у 2013 році, я також використовую такі інструменти, як Vagrant, Puppet & Amazon Web Services з кінця 2011 року.
Зараз так багато інших інструментів, які ми використовуємо для сучасної хмарної інфраструктури, такі як Ansible, Terraform, Packer & Kubernetes тощо. Використовуючи всі ці чудові технології, легко забути, що багато компаній все ще затримуються, підтримуючи старі, застарілі програми, що працюють на застарілій, погіршеній інфраструктурі.
Оскільки співпрацюючи з низкою клієнтів UKCloud, стало очевидним, що існує [велика] кількість компаній, які хотіли б почати використовувати власну інфраструктуру хмарних технологій, але не можуть просто кинути все і зробити стрибок до використання тих самих технологій, що і стартап з 5 чоловік! Існують проблеми, починаючи від необхідності підвищувати кваліфікацію працівників і закінчуючи кардинальною зміною всього додатка для роботи на вузлах без стану.
Мета цього посібника – ознайомитись із проблемами, які вам потрібно вирішити, і саме тим, який вибір ви маєте, коли йдеться про перенесення вашої застарілої програми в хмару.
Куди ти хочеш піти?
У сучасному світі хмарних обчислень не так просто точно визначити, де / що ви хочете, щоб було ваше рішення. У різних хмарах так багато технологій, які ускладнюють остаточний вибір. Однак важливо скласти план.
Ви хочете скористатися деякими чудовими послугами Amazon, такими як S3 & API Gateway, або хочете, щоб це був Lambda FaaS з потоками Kinesis? Або ви розглядаєте масове масштабування SQL за допомогою Google Spanner, або це API машинного навчання для запобігання втраті даних?
Можливо, ви хочете уникнути блокування постачальника або вам потрібен доступ до захищених мереж, таких як HSCN (N3), PSN-P або RLI, використовуючи компанію, таку як UKCloud.
Що робити, якщо вам потрібна гібридна система? Ви хочете використовувати Azure Cloud із деякими попередніми послугами, що надходять із більш легкого “Azure Stack”?
Контейнери вже не є настільки дизайнерським вибором – контейнери є даністю. Вам просто потрібно вирішити, де і як ви хочете їх розгорнути. Будь то розгортання власного кластера Kubernetes у OpenStack, або використання рішення PaaS, такого як RedHat OpenShift або Google Container Engine.
Прийняття рішення щодо технологій, які ви хочете використовувати, проти технологій, які вам потрібні , є настільки ж важливим, як вибір місця, де ви збираєтесь розгорнути свою програму. Однак важливо , але це розуміння того, що немає правильного чи неправильного. Немає нічого поганого у наявності служби Azure Cloud з деякими попередніми службами Azure Stack, які використовують службу Amazon Lambda та систему BigData від Google. Якщо це те, що вам підходить, і це те, що потрібно вашій програмі; Зроби це. Коли ви чуєте “Хмара” – це тепер означає “багатохмара”. Усі наші додатки в будь-якому випадку побудовані як мікросервіси, так? : wink: Ви завжди повинні враховувати, чи не є для вас проблемою блокування постачальника, однак, як тільки ви почнете користуватися такими інструментами, як Lambda, ви «застрягнете» з AWS на довгі дистанції.
Тільки після того, як ви зрозуміли, куди хочете піти, ви можете замислитися над тим, що у вас є зараз, і зрозуміти, як, до біса, ви туди потрапите. Почати з того, що є, дуже просто, не складаючи плану. Однак якщо ви не знаєте, куди йдете, ви ніколи не дійдете туди.
Де ти зараз?
Як зараз виглядає ваш додаток? Як правило, є 3 сценарії, в які ви впишетесь, або між ними.
Сценарій 1
Перший сценарій полягає в тому, що ваш додаток настільки монолітний, що існує лише одна кодова база, можливо, дві, якщо вам пощастить. Було б досить нечувано, щоб ви не використовували систему контролю джерел / версій, але цілком можливо. Ваш додаток, ймовірно, спілкується безпосередньо з гігантською базою даних SQL, яка з часом стає все повільнішою і повільнішою, незважаючи на те, що хтось створив якийсь зламаний механізм кешування, намагаючись забити найновіший аромат NoSQL, що існував там на той час, ймовірно, MongoDB. У системі, швидше за все, працює кілька завдань CRON, яких ніхто насправді не хоче торкатися, бо той, хто їх створив, давно покинув бізнес.
Якщо ви запитаєте когось у бізнесі, він зможе повідомити вам назву компанії, яка розміщує ваш додаток, і вам доведеться шукати запитання “фінанси”, щоб дізнатися, скільки це коштує. Якщо ви знайдете когось із доступом до оболонки і потрапите на сервер, ви, мабуть, виявите, що існує кілька сформованих файлів, таких як звіти PDF клієнта або щотижневі звіти KPI, створені одним із вищезазначених CRON. Ви, мабуть, навіть не хочете бачити, яке ядро Linux працює, тому що ви можете вільно підняти руки і сказати мені, що воно застаріле, і відкрите для тисяч вразливостей безпеки, включаючи ключ SSH Джона, навіть якщо він залишив компанію 6 місяців тому.
Проблеми: безпека, швидкість розробки, швидкість випуску, стабільність, масштабованість, продуктивність, аварійне відновлення, доступність
Куди ти хочеш піти? В ідеальному світі ви хотіли б переписати все це. Почніть заново в сучасному світі і поступово мігруйте свій трафік до нових послуг.
Якщо це ти; не хвилюйся, ти не одна. Я стикаюся з багатьма компаніями в цій ситуації і допомагаю їм вийти з іншого боку! : смайлик:
Сценарій 2
Другий сценарій, як правило, ви маєте трохи більше сучасного додатка; Ви, ймовірно, використовуєте Digital Ocean або старий акаунт RackSpace, де трохи сучасного джазу підкинули деякі люди, які були і не були. У вас є база даних SOLR для швидкого пошуку, і ви отримуєте щотижневий знімок ваших серверів. У вас є API, що сидить на іншому сервері, але це не RESTful; це SOAP і досить складне у використанні, мало документації. Він і так не використовується вашим додатком, він призначений лише для третіх сторін, які хочуть інтегруватися у вашу систему. На жаль, у вашому додатку все ще є деякі файли, які зберігаються на вашому сервері додатків, але принаймні він є напівбезпечним, оскільки у вас є SysAdmin, який знає, як зробити оновлення yum. Він / вона також заблокував ваш сервер, щоб дозволити лише користувачам із ключем SSH.
Весь ваш код знаходиться в GitHub, і один із попередніх розробників додав кілька модульних тестів, які запускаються (і проходять) у TravisCI. Хоча є десятки відділень; єдиною гілкою, яка безпечна у використанні, є “dev2” – усі інші застаріли, болить конфлікт. Кожен випуск – це нестійкий процес, але на щастя, у вас є тестовий сервер. Проте тестовий сервер працює з базою даних 18 місяців тому, коли інший розробник сказав, що йому потрібен дамп з реальної бази даних. Незважаючи на те, що у вас є приємний сценарій міграції баз даних, він трохи хиткий, і іноді потрібна ручна робота, щоб додати стовпець туди-сюди, щоб переконатися, що хтось може це перевірити.
Проблеми: швидкість випуску, стабільність, масштабованість, аварійне відновлення,
Куди ти хочеш піти? Цілком чесно, ви насправді не відчуваєте атмосфери повного перезапису, ви просто хочете розбити код на деякі менші служби та перевести їх у стабільне середовище. Компанії не дуже подобається ідея пов’язати послугу з однією технологією, і вона хотіла б тримати їхні можливості відкритими для подальшого розвитку.
Сценарій 3
Ті, хто в сценарії 1 або 2, хотіли б опинитися в сценарії 3. Якщо це ви, то ви вже використовуєте хмарну платформу, таку як Amazon. У вас є програма, яка розбита на кілька різних „служб”. Ви отримали REST Api, службу баз даних (Amazon RDS) і “інтерфейс”. Однак інтерфейс – це насправді програма PHP, яка розмовляє з сервером-сервером REST Api.
Один із вашої команди – «гуру AWS» (вона деякий час використовувала його на попередній роботі), і вона здається майстром (ess?). Вона не тільки створила 3 копії вашого реального сервера, кожна з яких має еластичний IP, вона також налаштувала балансир навантаження за допомогою ELB. Крім того, вона налаштувала групи безпеки, щоб гарантувати, що лише ваш офіс може отримати доступ до серверів через SSH.
Ваш додаток зберігає всі створені файли в S3, а ваш пакет TravisCI також чудово упаковує всі ваші розгортання у zip-файл у S3, готовий до того, що ваш хлопець SysAdmin зробить розгортання. Під час розгортання ваш гуру AWS виймає один із серверів з ELB, випускає додаток і тестує його, оновивши файл хостів. Якщо все добре, вона знову вмикає це на ELB, видаляє інший сервер і повторює процес.
Ви використовуєте GitFlow як шарм, але кожного разу, коли гілка потребує тестування, ваш хлопець SysAdmin повинен змінити гілку, яка розгорнута на тестовому сервері. Крім того, щопонеділка він повинен відмовитись від тестового RDS db і створити новий із прямого ефіру. Досить просте завдання, але займає пару годин.
Ваше середовище для розробки – це те, що хтось створив пару років тому, використовуючи Vagrant із маріонетками Це насправді не схоже на live, оскільки це система Ubuntu, де як live це CentOS, але вона працює досить добре, щоб перевірити більшість речей.
Проблеми: Випуск складний. Швидкість програми може бути покращена. У міру масштабування процес триватиме довше і довше. Середовище розробників не нагадує живий ефір. Обмежений моніторинг. Потрібно масштабуватися в інший регіон, але не знати точних кроків для відтворення.
Куди ти хочеш піти? Ви хотіли б розбити свій додаток на менші служби, вмістити їх та застосувати модель, керовану подіями. Ви хочете мати можливість відобразити свою інфраструктуру як код, щоб ви могли легко її створювати, коли вам потрібно. Ви хочете спростити процес розгортання за допомогою конвеєрів збірки. Рішення для моніторингу було б чудовим.
Отже, як можна дістатися з того місця, де ти знаходишся, туди, де ти хочеш бути?
Тут я б хотів детально розказати, як дістатися з A-> B. На жаль, навіть для тих сценаріїв, наведених вище, немає чарівної кулі. Однак важливим є спосіб роботи DevOps. Без DevOps ви будете боротися, і скоріш за все не зможете.
DevOps породжує культуру інновацій, високу спритність та приносить шалені швидкості для додавання вартості бізнесу. [1]
DevOps використовує автоматизацію для швидшої доставки додатків і забезпечує динамічну програмовану платформу. [1]
Те, що у вас є «Сценарій 1», це не означає, що вам доведеться переписати цілу систему. Просто ізолюйте одну з функцій / служб і розподіліть її. Створіть нову незалежну мікросервісну службу, яка працює, використовуючи потрібний вам стек технологій.
Існує продуманий процес: якщо ваша мікрослужба вимагає більше одного спринту чи два, то це не така вже й велика „мікрослуга”. Якщо ви розробляєте мікросервіси в спринті або два, і бізнес вважає, що вони не мають для них ніякої користі, це інвестиція з досить низьким ризиком. Побудова ітераційного значення є ключовим фактором.
Контейнери.
DevOps краще працює з контейнерами. [1]
Контейнери – це вже не питання «якщо», і це вже не питання «коли». Зараз час, і питання полягає в тому, «як». [2]
У вас є технологія упаковки та ізоляції програм із файлами, які потрібно запустити, що зменшує конфлікт, розділяючи проблеми. [1]
Кожна нова послуга, яку ви створюєте, має бути контейнерною мікрослугою. Створіть для нього автоматизований конвеєр збірки та навчіться розробляти свій новий спосіб роботи. Повільно, але впевнено ви перейдете у свій ідеалістичний світ!
Це не все звичайне плавання.
Стратегія.
Стратегія – це те, що лежить в основі вашої трансформації DevOps.
Створіть ключову стратегію, яка за допомогою сильних рішень висвітлює ключові слабкі місця. Це кричуща діра в безпеці в 15-річному додатку? Або це буквально «просто» той факт, що у «Сценарії 3» вам вкрай потрібно контролювати свої 15 мікросервісів, що працюють на 50 вузлах?
Іноді доводиться брати грубе з гладким, а задля бізнес-вимог ви відчуваєте, що намагаєтесь «відполірувати кашку». Буває. Це все частина міграції.
Прикладом може бути стара система, над якою я працював 4-5 років тому. Партнерська платформа для відстеження, яка займала до 5 секунд для перенаправлення користувача та до 20 секунд для відстеження продажу. Зовсім неприйнятно. Платформа була монолітною – потрібні були місяці, щоб переписати її з нуля і, можливо, навіть довше, щоб спробувати повторно врахувати фактори, але щодня компанія потенційно втрачала тисячі фунтів щодня. Замість того, щоб повторно писати, ми просто написали нову службу, яка приймає трафік і поміщає його в чергу обміну повідомленнями для обробки старої системи. З моменту створення до розгортання та міграції пройшло 4-6 тижнів, зменшивши час перенаправлення та розподілу продажу до <50 мс. Виграй.
Ми покинули стару систему? Ні. Чи впровадили ми елегантне сучасне рішення із швидким, ітеративним розробкою та постійним впровадженням? Так.
Рим не був побудований за день, як і ваша трансформація.
Справа не лише в тому, як повторно врахувати вашу заявку. Вам також не потрібно стрибати на ініціативу «спочатку хмара». Звичайно, це [ймовірно] ваша мета, але ви можете робити кроки дитини. Чи матимете ви деякі послуги попередньо, а деякі в хмарі? Чи будете ви використовувати якусь сторонній платформу SaaS для переміщення частини робочого навантаження? Це визначить ваша стратегія.
DevOps зроблено правильно – це відповідь на перехід до хмари. Не дозволяйте поганому досвіду DevOps відкладати вас. Звичайно, не дозволяйте нікому говорити вам інакше! : смайлик:
Дуже хочемо почути ваші думки, тому, будь ласка, коментуйте, якщо у вас є час!
Дякуємо за читання! : +1:
[1] – Джерело: Розмова Мішеля Існара – віце-президента з продажів RedHat EMEA
[2] – Tweet: https://twitter.com/BobbyJason/status/922855378634887168
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/migrating-cloud-you-ready-devops-bobby-deveaux-devops-consultant/.
Bobby DeVeaux, Cloud-DevOps Architect люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 