Особенности при миграции из Oracle в PostgreSQL (Life Hacks)

1 — Constraints (ограничения)

Хотя Oracle позволяет пользователям отключать и включать ограничения сколь угодно часто, это обычно не рекомендуется для любой СУБД, поскольку при неправильном выполнении это может привести к повреждению данных. В PostgreSQL ограничения вместо этого создаются как отложенные, и для их отсрочки можно использовать команду SET CONSTRAINTS. Параметр отложенного выполнения указывает время по умолчанию для активации ограничения. Если ограничение в Oracle нельзя отложить, его нужно будет отбросить и воссоздать как откладываемое, хотя иногда можно изменить ограничение, не отбрасывая его.

2 — Delete

При удалении данных в PostgreSQL для указания таблицы необходимо использовать синтаксис FROM, в Oracle же не требуется.

3 — Удаление объектов базы данных

В PostgreSQL разрешение на удаление объектов ограничено только владельцем таблицы базы данных или суперпользователем. Это не предоставляемая привилегия, хотя членство в роли, которая владеет объектом, может быть предоставлено. Если возможность удаления объектов базы данных в Oracle также предоставлено как членство в роли, то тогда необходимо будет переписать или перенастроить объект.

4 — Dual Table

Поскольку предложение FROM является обязательным в Oracle для каждого оператора SELECT, FROM DUAL используется для операторов SELECT, где имя таблицы не требуется. PostgreSQL не требует предложения FROM, поэтому FROM DUAL не требуется и обычно его можно опустить. Если в PostgreSQL требуется dual table, ее можно сгенерировать как представление.

5 — Пустые строки и NULL

В Oracle пустые строки имеют значения NULL, но они не считаются NULL в PostgreSQL. В Oracle можно проверить, пуста ли строка или нет, с помощью оператора IS NULL, но в PostgreSQL он вернет FALSE для пустой строки (и TRUE для NULL).

6 — Federation to Foreign Data Wrappers

Функция Oracle Federation позволяет пользователям обрабатывать таблицы из других баз данных, как локальные данные. Оболочки сторонних данных PostgreSQL более универсальны и позволяют подключаться к более широкому диапазону данных.

7 — GRANT

Команда GRANT действует аналогично в Oracle и PostgreSQL. Есть два основных варианта — они могут использоваться для предоставления привилегий для объекта базы данных и для предоставления членства роли.

При этом, не все привилегии Oracle доступны в PostgreSQL. Например, предоставление привилегии триггера для таблицы позволяет пользователям создавать триггеры, но в отличие от Oracle только владелец таблицы может удалять триггеры.

8 — Иерархические запросы

PostgreSQL не поддерживает START WITH. . .CONNECT BY, который Oracle использует для иерархических запросов. Вместо этого PostgreSQL использует WITH RECURSIVE.

9 — Joins with (+)

В Oracle есть специальный оператор (+) для выполнения левого и правого outer joins. В PostgreSQL эта функция отсутствует, поэтому необходимо указывать команду JOIN.

10 — Проверка NOT NULL

Для определения какие столбцы в таблице Oracle НЕ являются NULL, необходимо использовать команду CHECK (<column_name> IS NOT NULL). В PostgreSQL же вместо этого имеется столбец «attnotnull» в pg_attribute, в котором хранится информация о столбцах таблицы, в том числе – о столбце с Constraint NOT NULL.

11 — Преобразование PL / SQL в PL / pgSQL

Процедурный язык PostgreSQL PL/pgSQL во многих отношениях похож на Oracle PL/SQL. Оба являются императивными языками с блочной структурой и похожими форматами для присваиваний, циклов и условных выражений.

12 — Remote objects

Для доступа к remote objects можно использовать оболочку внешних данных (Oracle_fdw) для доступа к любой другой базе данных. Столбцы ROWID, CTID и IdentityPostgreSQL не имеет точного эквивалента псевдостолбцу ROWID в Oracle, который предоставляет адрес строки в таблице. CTID в PostgreSQL аналогичен, за исключением того, что его значение изменяется каждый раз при выполнении VACUUM. Вместо этого используются столбцы идентификаторов, значения которых создаются автоматически при создании строки и никогда не изменяется. Значение можно указать, чтобы оно создавалось ВСЕГДА или ПО УМОЛЧАНИЮ. GENERATED BY DEFAULT позволяет пользователю вставить или обновить значение, а не использовать значение, сгенерированное системой.

13 — Sequences

Sequences имеют другой синтаксис в Oracle и PostgreSQL, и их необходимо обновлять вручную или с помощью скрипт.

14 — SUBSTR

Функция SUBSTR по-разному работает в Oracle и PostgreSQL. В Oracle оператор SELECT SUBSTR (‘ABC’, — 1) FROM DUAL; возвращает «C», а эквивалентный SELECT SUBSTR (‘ABC’, — 1); в PostgreSQL вернет ABC.

15 — MERGE INTO

В PostgreSQL отсутствует оператор MERGE INTO, в отличие от Oracle.

16 — Синонимы

PostgreSQL не поддерживает синонимы. Вместо CREATE SYNONYM Oracle для доступа к удаленным объектам в PostgreSQL можно использовать SET search_path для включения удаленного определения.

17 — SYSDATE

Функция Oracle SYSDATE возвращает дату и время (в часовом поясе сервера). PostgreSQL не имеет соответствующей функции, но существует ряд методов для получения даты и времени для различных целей: statement_timestamp () дает текущую дату и время с начала текущего оператора; now () и transaction_timestamp () дают дату и время с начала текущей транзакции, а clock_timestamp () дает текущую дату и время с момента выполнения функции.

18 — TO_DATE

Функция to_date () как в Oracle, так и в PostgreSQL возвращает тип данных даты. Однако тип данных даты PostgreSQL предоставляет дату (год, месяц, день), а значение типа данных даты Oracle предоставляет дату и время (год, месяц, день, час, минута, секунда). Чтобы избежать этой несовместимости, используйте to_timestamp () PostgreSQL. Решением этой несовместимости является преобразование TO_DATE () в TO_TIMESTAMP ().

19 — Транзакции

Oracle всегда использует транзакции, но в PostgreSQL их нужно активировать. В Oracle выполнение любого оператора запускает транзакцию и заканчивается оператором COMMIT. В PostgreSQL транзакция начинается с оператора BEGIN, а также заканчивается оператором COMMIT. Уровни изоляции транзакций одинаковы в PostgreSQL и Oracle, и Read Committed является уровнем изоляции по умолчанию для обоих.

20 — Обработка ошибок транзакции

PostgreSQL создан для облегчения управления транзакциями и обработки ошибок с полной поддержкой ACID и уровнями изоляции. Он также способен обрабатывать ошибки времени выполнения и предоставляет надежные коды ошибок и сообщения для PL/pgSQL или кода приложения. Однако они обрабатываются иначе, чем Oracle, поэтому изменения все же необходимо внести. Вот несколько советов по оптимизации обработки ошибок в PostgreSQL:

  • Контроль транзакций внутри PL / pgSQL не разрешен: вы не можете зафиксировать или откатить транзакцию внутри хранимой процедуры.
  • Когда во время транзакции возникает исключительная ситуация во время выполнения, транзакция должна быть отменена, перед выполнением другой операции, потому что транзакция прерывается, когда обнаруживает ошибку. Журнал приложения покажет следующее сообщение об ошибке:
  • Используйте блок BEGIN… EXCEPTION… END для обработки исключений, чтобы код улавливал любые возникающие ошибки. Это автоматически устанавливает точку сохранения перед блоком и откатывается к ней при возникновении исключения. Имейте в виду, что, поскольку блоки исключений создают точку сохранения, они дороги, поэтому добавляйте их осторожно.
  • Сопоставьте коды ошибок и типы исключений из Oracle в PostgreSQL. Хотя некоторые коды ошибок одинаковы в обоих случаях, другие различаются. Язык программирования также влияет на это — например, специфичные для Oracle исключения JDBC должны быть заменены либо общими исключениями между базами данных, либо специфичными для PostgreSQL.
  • Обеспечение правильной обработки транзакций и ошибок в базе данных PostgreSQL является важной частью процесса миграции и обычно требует тщательного анализа базы данных и кода приложения.

Этапы оценки при переходе с коммерческих СУБД на PostgreSQL

1 — Общая оценка

Данный этап проводится, чтобы оценить насколько легко или сложно будет выполнить миграцию на PostgreSQL. Сначала следует провести тщательный анализ проблем, связанных с технологиями, и оценить совместимость клиента, сервера приложений, доступа к данным и функций базы данных.

2 — Оценка совместимости

Прежде всего надо убедиться, что необходимое ПО сертифицируется PostgreSQL. Если данной сертификации нет — нужно будет договориться с владельцами ПО добавить поддержку PostgreSQL, либо выбрать другое ПО.

После проверки совместимости исходной и целевой базы данных, необходимо проверить следующее:

  • Ресурсы сервера (память / дисковое пространство / открытые сетевые порты между источником и местом назначения).
  • Операционная система.
  • Программное обеспечение для переноса данных и соответствующие драйверы установлены и настроены.

3 — Оценка кода приложения

Чем больше код приложения зависит от специфичных для коммерческой СУБД фреймворков, а не от открытых классов, тем сложнее становится миграция. Объем необходимых корректировок зависит от архитектуры приложения и уровня подключения к базе данных. Преобразование должно быть относительно простым, например, есть код Java, который использует общие классы JDBC, а не специфические для конкретной СУБД.

Ситуация усложняется, если вы используете встроенный язык программирования. Такой как Oracle Pro * C, динамически построенный SQL, или связываетесь с библиотеками, специфичными для Oracle, такими как: OCI или классы Oracle JDBC. Их корректировка требует твердого понимания базовой логики приложения и должна быть тщательно протестирована.

4 — Оценка архитектуры и очистка

На процесс миграции могут существенно повлиять настройка и архитектура базы данных и ее содержимого. Миграция предоставляет хорошую возможность очистить архитектуру и содержимое базы данных от лишнего — объектов, которые больше не нужны. Например старые временные таблицы или резервные копии данных, статических исторических данных, либо перейти к архивному хранилищу. А также уменьшить размер базы данных и ресурсы, необходимые для резервного копирования и восстановления.

Переход на PostgreSQL также открывает возможность разделения обработки онлайн-транзакций (OLTP) и аналитики по разным хранилищам, что может улучшить как оперативность, так и возможности аналитики.

5 — Преобразование схемы

Последним шагом в этапе Оценки является выявление и устранение различий в схеме и форматировании данных между коммерческой СУБД и PostgreSQL. Крайне важно внести эти изменения до миграции данных, чтобы избежать неприятных и трудоемких ошибок в PostgreSQL.

PostgreSQL поддерживает стандартный синтаксис SQL и типы данных ANSI SQL. С помощью инструментов следует идентифицировать неподдерживаемые объекты, а затем преобразовывать их вручную с помощью синтаксиса, поддерживаемого PostgreSQL или обходных путей.

Приглашаем на семинар: Оптимизация DWH на платформе Vertica

Компания DBI совместно с Vertica и при поддержке компании Mont приглашает Вас принять участие в семинаре: Оптимизация DWH на платформе Vertica.
В рамках семинара мы расскажем о методах построения эффективной аналитической системы, обсудим этапы эволюции подхода к хранению и анализу данных на базе технологий Vertica, а также вместе с экспертами обсудим интересующие вопросы.
Специальные гости: эксперты S7 Airlines — поделятся опытом развития DWH.
Мероприятие состоится 15 октября 2021 года, в 15:00, в ресторане Lambic Brasserie на Новослободской, в формате “meetup”, что предполагает обмен опытом и неформальное общение.
Участие в семинаре бесплатное, но в связи с ограниченным количеством мест, требуется предварительная регистрация:
Программа:
15:00 — Регистрация участников и приветственный кофе;
15:30 — Унифицированное аналитическое хранилище — новый этап в развитии аналитических платформ;
16:00 — Сценарии использования Vertica для оптимизации DWH/КХД;
16:20 — Бизнес-кейс: Эволюция DWH в компании S7;
17:00 Кофе-брейк;
17:10 — Администрирование и техническая поддержка — помощь в разворачивании, мониторинге, сопровождении DWH на базе Vertica;
17:30 — Workshop: Демонстрация аналитического аппарата Vertica на примере моделирования поведения пользователя на сайте букинга отелей;
18:00 Ужин, неформальное общение + «Круглый стол»: преимущества и недостатки использования MPP-баз данных для построения DWH.

Будем рады встрече с Вами!

#meetup #dbi #mont #vertica #S7Airlines

Пять способов для сокращения стоимости облачных сервисов

Одно из преимуществ использования облачных технологий — это сокращение расходов на инфраструктуру и оплата только, того, чем реально пользуются сотрудники.
Но всегда ли это так? И можно ли и тут снизить расходы?
Наша команда DevOps инженеров предлагает 5 практических подходов к снижению стоимости облачных ресурсов.

Тэги

Тэги — это основа успешной и эффективной модели регулирования расходов в облаке. Они позволяют точнее определять основные точки расходов и контролировать их во всё возрастающем количестве используемых ресурсов.
Представьте облачную инфраструктуру из 20 виртуальных машин, одни тестовые или девелоперские, другие продуктовые и еще несколько не используются вообще. Если их называли просто VM1, VM2… , то через некоторое время будет просто невозможно определить, что есть что.

Правильная стратегия названий позволит уйти от этих проблем, но это потребует пересоздания уже имеющихся ресурсов. Благодаря тэгам вы можете сохранить текущие названия ресурсов и добавить к ним тэги для контроля, такие как «критичность системы», «статус использования», «владелец». Благодаря этому вы всегда будете знать в каком состоянии система и к кому обратиться в случае проблем.
Это так же позволяет вам быть более гибким в процессе смены владельцев или метода использования ресурсов.

Внедрение и использование тэгов

Стандартизированный подход к тэгам позволяет улучшить контроль и отслеживаемость всех ресурсов и нагрузок. К примеру, используя тэг «прод системы» вы можете быстро определить нужные системы. Это позволит настраивать доступы к тем или иным системам и отследить стоимость используемых ресурсов. Теперь вы точно сможете определить на основании каких изменений стоимость услуг выросла и обратиться с вопросом к конкретному отделу компании.

Очень важно внедрить процесс выставления тегов и поддерживать их в актуальном состоянии для достижения максимальной эффективности.

Ну и конечно вы можете облегчить процесс используя ПО, например, CloudCheckr который будет анализировать тэгированные ресурсы и предлагать возможности для сокращения расходов.

Организации «новички» в облачных технологиях недооценивают силу тэгов. И в конце концов сталкиваются с непрогнозируемыми тратами на облако. Метод использования тэгов может всё изменить, показать болевые точки и полную фрагментированную картину.

Автоматическое масштабирование и оптимизация размера

Наиболее весомое основание для перехода в облачную структуру у многих компаний — это уход от избыточного потребления. Но, к сожалению, это не работает автоматически. Лучший способ оптимизировать ресурсы и их стоимость – оптимизация размеров инстансов. Хотя многие пренебрегают этим, когда впервые сталкиваются с облаком.

Согласно практике, AWS оптимизация размера — это постоянный процесс «соотношения вашей нагрузки типов и размеров инстанса который сможет ее обработать. Это так же процесс контроля за уже созданными инстансами на предмет отключения или уменьшения их мощности для снижения их стоимости без воздействия на иные факторы».

Лучшее решение — это комбинирование оптимизации размера инстанса и автоматического масштабирования. Современная облачная инфраструктура должна быть сконфигурирована в соответствии с текущими потребностями в максимально выгодном ключе, но с возможностью быстрого увеличения мощности. Автоматическое масштабирование работает в двух направлениях – горизонтальном и вертикальном. Оно может возникать как при внезапном увеличении/снижении нагрузки, но также может быть и запланированным процессом.

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

Для обслуживания минимальной обязательной нагрузки можно использовать резервируемые инстансы. Это позволит значительно сократить стоимость необходимой инфраструктуры т. к. забронированные на год или более инстансы стоят значительно дешевле.

Если вы спросите сколько инстансов нужно развернуть, то ответом будет ровно столько, сколько нужно. Не больше, не меньше.

Не забывайте стоимость тестовых систем

Многие организации начинают свой переход в облако с тестовых систем. В теории тестовые системы должны быть выключены после использования. Однако остаются артефакты, которые продолжают требовать оплат.

Избежать не контролируемых трат позволит настройка оповещений о том, что стоимость ресурсов больше ожидаемой. Так вы можете увидеть ресурсы, которые все еще работают хотя должны быть отключены.

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

Объединенный билинг и поиск подходящих лицензий

У облачных провайдеров существуют различные системы оплаты. Поиск лучшего решения может определить новый путь оплаты облака.

Большинство компаний начинает свой путь в системе облачных технологий по подписке «платим за то, что используем». Это хорошо для теста облака, но вести бизнес в таком ключе не очень выгодно. Существует несколько вариантов облачных подписок которые могут сократить стоимость и улучшить контроль за ресурсами:

  • Работа с облачным провайдером позволяет более плотно работать с поддержкой облачного провайдера.
  • Энтерпрайз соглашения позволяет получить дополнительные скидки на текущие используемую инфраструктуру.
  • Тестовые подписки могут быть более выгодным подходом для команд разработчиков. Эти подписки значительно дешевле, но в них есть ограничения по доступности ресурсов.
  • Объединенные отчеты по тратам в облаке позволяют корректнее отслеживать затраты всей организации в целом.
  • Гибридные лицензии позволяют сократить расходы на виртуальные машины и базы данных.
    Бесплатные лицензии помогают в обучении новых специалистов и тестировании. В некоторых из них доступно использование ПО, к примеру, Visual Studio.

AWS Spot и Azure Spot

Большинство облачных провайдеров такие как AWS и Azure предлагают существенные скидки на работу с неиспользуемыми ресурсами. Как правило вы выставляете цену за час, которая вам выгодна и ресурс работает только тогда, когда цена не превышает данную стоимость.

Наши инженеры советуют использовать спот ресурсы для тех задач, которые не пострадают от внезапной остановки сервиса. Как уже говорили, система настроена так, что ресурсы выделяются и работают только при достижении цены на них определенного вами уровня. Этот подход позволяет сократить расходы на такие задачи как: аналитика данных, бэкграунд процессы и пакетных заданий.

Надеемся эта статья будет полезна для вас. Свяжитесь с нами, если хотите узнать, как наша команда сможет вам помочь в данном вопросе.

DBI участвует в Yandex Scale 2021

Спешим поделиться новостью: DBI выступает партнером компании Yandex.Cloud на мероприятии Yandex Scale 2021! Приглашаем всех желающих присоединиться к нам в этой масштабной онлайн-конференции 24 сентября с 10:00 до 17:00.

Команда Yandex.Cloud расскажет о стратегических планах, а также обновлениях сервисов платформы. Клиенты и партнеры поделятся реальными кейсами и решениями в облаке, а пространство для общения позволит обменяться идеями и пообщаться в режиме реального времени. Минимум маркетинга, максимум полезного контента.

Участие в конференции бесплатное, узнать больше и зарегистрироваться можно по ссылке: https://scale.yandex.ru/partners#scale-form

#YandexScale2021 #DBI #YandexCloud

На что обратить внимание при миграции с Oracle на PostgreSQL

Столбцы при переходе с Oracle на PostgreSQL

До версии 12 в PostgreSQL не было эквивалентов виртуальных столбцов, поэтому пользователям предлагалось изменить их на представления при миграции. Теперь PostgreSQL предлагает сгенерированные столбцы, которые имеют много общих черт с виртуальными столбцами Oracle.

Ограничения при переходе с Oracle на PostgreSQL

В обеих системах баз данных ограничения Primary и External Key, Check, Not-Null и Unique работают более или менее одинаково.

Идентификаторы при переходе с Oracle на PostgreSQL

Oracle преобразует имена схем, таблиц, столбцов и функций в верхний регистр, если имя не указано в кавычках, в то время как PostgreSQL преобразует их в нижний регистр (также если не указано в кавычках). Пока приложение постоянно цитирует или не цитирует идентификаторы, вы должны быть в безопасности.

Индексы при переходе с Oracle на PostgreSQL

B-tree и нисходящие индексы должны работать в PostgreSQL. Reverse keys, bitmap и join indexes в настоящее время не поддерживаются. Глобальный индекс не поддерживается в PostgreSQL.

Разделы при переходе с Oracle на PostgreSQL

Разделы Hash, List и Range должны работать в PostgreSQL после миграции.

Таблицы при переходе с Oracle на PostgresSQL

CREATE TABLE в основном совместим, за следующими исключениями:

В PostgreSQL отсутствуют глобальные временные таблицы. Вместо этого используйте временные таблицы (LOCAL TEMP).

Параметры предложения хранения (INITRANS, MAXEXTENTS) не распознаются в Postgres и должны быть удалены.

Для параметра Oracle PCTFREE замените его фактором заполнения PostgreSQL.

Топ 5 преимуществ работы с облачными провайдерами

В этой статье мы ответим на вопросы для чего нужны провайдеры управления облачными сервисами и как переход под управление такого провайдера сможет помочь вам в вашем деле.

Доступ к широкому спектру квалифицированных сотрудников

Проблема недостатка квалифицированных специалистов стоит на первом месте у большинства организаций, работающих с облачными технологиями .

Эта проблема касается как процесса миграции, так и операционных задач. Чаще всего внутренняя команда бизнеса недостаточно квалифицирована и опытна, чтобы выполнить такую трудоемкую и многосоставную задачу как миграция на облачную инфраструктуру.
Конечно, вы можете начать процесс миграции с обучения вашего персонала, но это займет большое количество времени и значительно отложит конечный результат.

Провайдеры управления облачными сервисами такие, как DBI помогают решать такие задачи.

Если вы быстро растущая IT компания и расширяетесь из-за увеличения количества клиентов вам потребуется быстрое расширение инфраструктуры. Вот здесь и нужны мы, как провайдер управления облаком для помощи вашей IT команде. Вы сможете полностью сосредоточится на бизнес-процессах и других важных моментах, пока мы будем работать с вашим облаком.
Так же работа с провайдерами управления дает доступ к высоко квалифицированным специалистам в любой момент времени. Вам нужен ДБА на 4 часа? Всегда пожалуйста.

24x7x365 поддержка по доступной цене

24x7x365 поддержка — это серьезный вызов для любой компании, потому что вам понадобится целая команда сотрудников, расписание дежурств, инцидент менеджмент и т.д. И хотя 24x7x365 поддержка — это то, к чему должен стремится любой бизнес, но для маленьких компаний содержать отдельную команду только для этого экономически не выгодно.
Здесь на помощь приходят поставщики управления облачными сервисами. Они собирают несколько компаний которым нужна такого рода поддержка и этим окупают свою работу. А клиент получает квалифицированных специалистов, которые берут на себя обязательства по работе с вашими запросами 24x7x365.

Делегируйте нам «рутинную» работу

Тут мы еще раз повторим тезис о том, что поставщики управления облачными сервисами, как эксперты могут взять на себя заботу о вашей облачной инфраструктуре, в то время как вы можете полностью сосредоточится на том, что делаете вы: создаете новый высококлассный продукт или предоставляете уникальный сервис.
Правильное делегирование обязанностей одна из основ успеха.

Работа с провайдерами облачных сервисов

Зачастую у поставщиков управления облачными сервисами очень тесный контакт с провайдерами облачных технологий. Это означает, что мы из первых рук получаем информацию о новых технологиях и тренинги по ним.
Так же мы участвуем в программах бюджетирования от провайдеров, с помощью которых мы можем снижать стоимость миграции для клиента!
DBI на сегодняшний день является ключевым партнером для таких облачных провайдеров, как: Oracle, Microsoft, Amazon и IBM.
Так же в нашей команде более 20 сотрудников являются сертифицированными специалистами в области облачных технологий.

DevOps автоматизация и многократно используемый код.

Основное преимущество работы с профессиональными поставщиками управления облачными сервисами является автоматизация развертывания облачной инфраструктуры, с использованием подхода «Инфраструктура как код» (англ. Infrastructure-as-Code; Iac). Это подход для управления и описания инфраструктуры через конфигурационные файлы и скрипты, без необходимости взаимодействовать с графическим интерактивным интерфейсом облачного провайдера или вручную редактировать множество конфигураций на серверах.

Подход «Инфраструктура как код» позволяет выстроить библиотеку готовых решений и позволяет значительно ускорить процесс миграции, а также упростить контроль за выстроенной инфраструктурой в будущем. Нами уже создано огромное количество плейбуков, скриптов, темплейтов в следующих технологиях:

  • RedHat – Ansible
  • PuppetLabs– Puppet Enterprise, Relay
  • Hashicorp– Terraform, Packer, Vault и т.д.
  • GitHub– GitHub Enterprise, GitHub Actions
  • Microsoft– Azure DevOps pipelines, ARM templates, Azure Blueprints & policy и т.д
  • AWS– AWS CodePipelines, CloudFormation
Если вы заинтересованы и готовы вступить в ряды тех, кому мы помогаем делать их бизнес лучше, пожалуйста, свяжитесь с нами.

Технические долги

Большинство компаний сталкиваются с огромным количеством технических «долгов» во время миграции в облако.
В этой статье мы рассмотрим 5 путей как DevOps может помочь их решить.

Что такое технический «долг»?

Технический «долг» – не оптимальные технические решения, накопленные за все время жизни приложения. Такие вещи становится все сложнее и сложнее исправлять и в конце концов эти инициативы просто останавливаются.

К примеру, плохо описанный процесс управления состоянием (state management) может сильно усложнить горизонтальное расширение. Перед тем как расширять структуру вам придется переписать ту часть кода, которая отвечает за управление состоянием. Это и называют техническим «долгом».

Так же технические «долги» встречаются и в операционной деятельности.
Все еще работаете на Windows Server 2008, or Ubuntu 11.04 которые не поддерживаются производителем?
Не установили последний патч по безопасности? Это и есть технический «долг».

Как DevOps может помочь?

Создайте DevOps команду

Один из принципов devops это создание небольшой команды, которая несет ответственность за весь жизненный цикл приложения. И так как эта команда и особенно продакт-менеджер каждый день сталкиваются с этими проблемами, они будут максимально заинтересованы в их устранении.

Простые советы для борьбы с техническими «долгами»

Во-первых, нужно замечать и следить за техническими «долгами» в своем продукте.

Во время работы над продуктом помечайте (в Jira, Azure DevOps или Git) не оптимальные элементы как «techDebt». И выделять время в каждом спринте на эти задачи.
Мы советуем начать с 20% времени, выделяемого на спринт.

После этого в рамках ретроспективной работы с каждой командой оцените текущий уровень ваших технических «долгов». Если большинство оценит эту проблему высоко, то стоит увеличить количество часов в спринте на работу с «долгами», до того момента пока «долги» не перестанут мешать корректной работе продукта.

И конечно старайтесь не создавать новых технических «долгов». Используйте таблицу возникновения «долгов» чтобы оценить решения архитектора и минимизировать «долги». Если вы все же решили оставить технический «долг», то контролируйте его и рассчитывайте загрузку так, чтобы вы смогли его исправить в следующих спринтах.

Построение общих сервисов самообслуживания

Все чаще компании создают общие сервисы для поддержки команд ответственных за продукты. Платформы основанные, на таких сервисах помогают избегать технических «долгов» при построении цепочек компонентов. Такие сервисы должны быть созданы в соответствии с запросами разработчиков и лучшими практиками для создания таких систем. Они могут быть, как сторонними SaaS-решениями, так и полностью собственными решениями.

Хорошая платформа — это общее дело. Она не должна быть черным ящиком для разработчиков, поэтому построение платформы стоит начать с изучения опыта открытых проектов и возможности применить эти решения в ваших внутренних платформах.

Немного о InnerSource

В определении InnerSource от InnerSource Commons говорится «консолидирует опыт развития open source решений для помощи внутреннего развития компании».
Команды, работающие с платформой, должны быть ключевой точкой изменений и быть готовым к ним. Репозитории с кодом должны быть общедоступны и любой желающий может внести изменения после согласования с управляющей командой.

Автоматизация

Неотъемлемой частью DevOps является автоматизация процессов.
Большая часть вышеупомянутых внутренних платформ выстраиваются и используются автоматизировано. Сервисы, которые предоставляют платформы, часто являются наборами инструментов для автоматизации, предназначенными для использования продуктовыми командам.

Как автоматизация может помочь с техническим «долгом»

Для примера возьмем процесс управления инфраструктурой и на его примере рассмотрим, как «инфраструктура как код» и «конфигурация как код» помогут нам в борьбе с техническим «долгом».

Несовместимые системы — это наиболее часто встречающийся вариант технического «долга». Когда ваше приложение работает в среде разработки, но не работает ни в препроде ни в проде чаще всего причиной будет несовместимость систем. Это могут быть как настройки ОС или приложения, так и тысячи межсервисных настроек, с которыми работает приложение. И то время, которое вы тратите на устранение этой проблемы и есть стоимость вашего технического «долга».

«Инфраструктура как код» и «конфигурация как код» позволят вам создать инфраструктуру в точности так как вы ее задумали. А с помощью таких инструментов как Terraform и Puppet, вы можете сконфигурировать ее на каждом инстансе идентично. А контейнеризация выводит это на следующий уровень, но об этом позже.

Время, которое вы НЕ потратили на поиск и решение инфраструктурных проблем, вы можете использовать на погашение других технических долгов, что ведет к «эффективному циклу автоматизации».

Система автоматизации «как код» дает еще ряд преимуществ. Весь код автоматизации хранится в репозитории типа GitHub, что дает возможность быстрого поиска нужных частей, их внедрения и улучшения основанных на запросах пользователей. Это позволяет сохранять код в актуальном состоянии и избегать накопления технического «долга».

Контейнеры для упрощения внедрения и управления приложением

Что такое контейнеры и как они могут помочь?

Если говорить коротко, то контейнеры позволяют вам сохранить ваше приложение, его настройки, настройки ОС в одной небольшой связке, которую можно легко развернуть, что сэкономит значительное время на конфигурации перед запуском.

Как и с инфраструктурным менеджментом, мобильность, которую дают контейнеры, может облегчить буквально все. Инструмент для оркестрации контейнеров, к примеру Kubernetes
позволяет автоматизировать систему жизненных циклов контейнеров. Это дает возможность DevOps команде не отвлекаться на операционные задачи, а заниматься более высоко уровневыми задачами (архитектура приложения и тд.)

При построении новых облачных приложений обычно используют контейнеры для улучшения гибкости подхода, наращивания мощности при уменьшении общей стоимости.
Архитектура микросервисов отлично работает как с контейнерами, так и с разделенными DevOps командами, отвечающими за продукт, о которых мы писали выше. У каждого микросервиса должен быть не большой, ограниченный список задач и команда поддержки. Это позволит в разы лучше контролировать процесс доработок и не накапливать технические «долги». Это беспроигрышный вариант.

Использование DevOps для построения API-ориентированной модели

Модель с использованием микросервисов это один из возможных вариантов реализации API-центрированной модели. Глава Amazon Джеф Безос поставил задачу своим сотрудникам пользоваться только API при взаимодействии с системой под угрозой увольнения.
Конечно, в вашей организации все может быть не так сурово. Тем не менее поощрение команды работать с API четко определенных версий, это хороший метод для ухода от технических «долгов». Чаще всего «долги» копятся из-за разных методов доступа приложений к сервисам и данным, которые не соответствуют друг другу. К примеру, команда А читает данные из таблицы созданной командой Б. И если команда Б поменяет схему для своих нужд, то этим они непреднамеренно нарушат интеграцию с приложением команды А.

API делают эти зависимости гораздо более заметными и менее уязвимыми. Каждый продукт должен придерживаться опубликованного API с понятными дорожными картами и политикой изменений. Если на поздних стадиях нужна смена API, то выпускают новую версию, и определяется время, которое будет поддерживаться «старая».

Системы DevOps, к примеру CI/CD практика непрерывной интеграции и непрерывного развертывания кода обеспечивает сквозную прослеживаемость от юзер стори до реализации, а также позволяет разработчикам работать быстрее с меньшими рисками и с меньшими техническими долгами.
Если вы контролируете и помечаете места с техническими «долгами», как обсуждалось ранее, вы увидите результат достаточно быстро. А автоматизация процесса поможет сконцентрироваться на нуждах потребителя.