Руководство по миграции на Oracle SaaS
для независимых разработчиков ПО

За последние несколько лет мы перенесли более 60 SaaS-приложений в Oracle Cloud Infrastructure. Данные приложения поддерживают основные корпоративные функции в восьми отраслевых вертикалях и позволяют обслуживать более 199 000 клиентов по всему миру.

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

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

 
Информационные центры объединены:
с 80 до 11
 
Капитальные затраты снижены на
80%
 
Расходы на инфраструктуру снижены на
64%
 
Расходы на ПО снижены на
42%
 
Количество разработчиков программного обеспечения снижено с
28 до 10
 
Время подготовки сокращено на
98%

Резюме для высшего руководства

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

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

Данное руководство по миграции на программное обеспечение как услугу (SaaS) для независимых разработчиков ПО основано на опыте, накопленном нами при миграции более 60 SaaS-приложений на Oracle Cloud Infrastructure (OCI). Данные приложения поддерживают основные корпоративные функции в восьми отраслевых вертикалях и позволяют обслуживать более 199 000 клиентов по всему миру. При переходе на облачную модель вы можете столкнуться с проблемами, с которыми уже сталкивались наши сотрудники, и в этом случае вам будут полезны реализованные нами решения. В этом руководстве мы обобщаем свой опыт на всех этапах перехода и описываем важные идеи и наблюдения, которые могут вам помочь. Приглашаем также посетить сайт Oracle@Oracle, где опубликовано более десятка информационных документов и блогов, посвященных переходу на облако и нашим лучшим практикам, трудностям и извлеченным нами урокам.

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

Глава 1. Двигатели трансформации

Начало вашего пути к облаку

Любой процесс перехода на облако, включающий миграцию приложений, будет непростым. Тем не менее, при всей сложности, на пути к облаку есть несколько четко определенных пунктов назначения. Один из таких пунктов связан со степенью "готовности к облаку" целевого приложения. Насколько приложение должно быть готово к работе с облаком, чтобы вы могли перейти на облако в нужный для вас момент? В этом документе мы опишем некоторые из этих пунктов и выделим лучшие практики и уроки, которые мы извлекли на своем опыте. Ключ к успеху — заранее четко определить цели миграции, чтобы можно было принимать оптимальные решения об их достижении. Вам предстоит выбрать свой собственный путь. В ходе перехода разработчики, сотрудники и руководители должны будут оценить и принять множество решений о дальнейших действиях.

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

Масштабируемость

Облачные сервисы обеспечивают масштабируемые вычислительные мощности — намного выше, чем это возможно для управляемой инфраструктуры —, позволяющие вашему бизнесу расти в соответствии с рыночными возможностями. Облачная инфраструктура как услуга (IaaS) и платформа как услуга (PaaS) позволяют независимым разработчикам программного обеспечения сосредоточиться на создании масштабируемых архитектур с использованием современных компонентов. Дополнительным преимуществом миграции является тот факт, что освобождение разработчиков компании от управления ИТ-операциями и их масштабирования позволяет сосредоточить внимание на настройке и оптимизации производительности.

Модернизация

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

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


"Миграция на облако 2-го поколения позволила Oracle успешно предоставлять услуги с помощью надежной модели DevSecOps, а также позволила нам поддержать преобразование в компаниях наших клиентов. Теперь мы выпускаем программное обеспечение ежедневно и сократили время подготовки на 98%." —Картик Мурали, старший главный менеджер по стратегии продукта, глобальные бизнес-подразделения Oracle

oracle@oracle


Стандартизация

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

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

Оптимизация доходов

Оптимизации доходов можно достигнуть двумя основными способами. Первый и самый очевидный способ — снижение расходов. Устранение информационных центров благодаря использованию IaaS не только переводит финансовую модель с капитальных затрат на операционные, но и обычно приводит к значительной экономии совокупной стоимости владения. Менее очевидный способ — снижение расходов за счет рационализации технологического стека, используемого в портфеле приложений, перенесенных в облако. Общие наборы инструментов создают институциональные знания и устраняют расходы, связанные с специальным обучением нестандартным инструментам. Помимо этого, общие наборы инструментов, рассматривающих инфраструктуру как код, обеспечивают автоматизацию, которая в конечном итоге экономит время и трудозатраты. Наконец, команды, которые специализируются в фундаментальных областях, применимых ко всему портфелю (таких как безопасность), больше не обязаны обучать экспертов в команде каждого отдельного продукта.

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

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


WorkForce Software переносит свое решение для управления персоналом в Oracle Cloud Infrastructure, повысив производительность на 30%.

Workforce" Результатом стали финансовые показатели, которые позволили нам мгновенно сэкономить от 30 до 35% капитальных затрат, а благодаря отличной производительности в результате OCI, рентабельность инвестиций, которую мы обеспечиваем с помощью нашего пакета, продолжает расти." —Майк Морини, генеральный директор WorkForce Software

Узнать больше


Пути к ценности в облаке

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

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

  • Уход от устаревших информационных центров. Управление информационным центром — дорогое удовольствие. Здания, люди, электроснабжение, охлаждение, техническое обслуживание и модернизация — это лишь некоторые из повседневных задач. Многие компании активно работают над уменьшением или устранением своей зависимости от информационных центров, оценивая портфели приложений для кандидатов, которые предстоит переезд с территории предприятия. Приоритетом является перевод приложений из размещенных, управляемых хостинговых или локальных информационных центров, чтобы снизить или исключить капитальные затраты. Зачастую используется стратегия «подъем-и-сдвиг», при которой приложение переносится как есть на сервер без операционной системы или в виртуальную машину в облаке.
  • Развитие стека технологий. В этом случае компании начинают постепенно вносить изменения в приложения, что потребует дополнительных инвестиций — но и потенциально принесет больше пользы — со временем. Примером этого может послужить замена локальных версий Oracle Database облачной автономной базой данных Oracle Autonomous Database без внесения серьезных изменений в само приложение. Иногда такой подход называют «переход и улучшение».
  • Все ставки на облачные технологии. Преимущества полного изменения архитектуры приложения для обеспечения готовности к облаку могут перевесить затраты на поддержание в рабочем состоянии менее зрелого приложения при реализации одного из описанных выше сценариев. Облачные приложения сильно распределены по своей природе — они часто создаются с учетом 12-факторных принципов — и, таким образом, разрабатываются так, чтобы быть независимыми от базовой архитектуры. Таким образом, приложения продолжают работать, даже когда инфраструктура, лежащая в их основе, выходит из строя. Другими словами, стоит оценить, имеет ли этот путь смысл для целевого приложения, поскольку переход на облако, безусловно, будет проще, чем перенос приложения, тесно связанного с базовой инфраструктурой.
Электронная книга Cloud Native Patterns
Чтобы узнать о том, как Oracle определяет облачные среды, о происхождении облачных приложений и передовых методах их создания, прочтите эту электронную книгу.

Еще один способ представить себе эти сценарии — рассмотреть весь спектр действий, которые можно предпринять с целью приблизить корпоративное приложение к облачной архитектуре, одновременно перенося его в Oracle Cloud Infrastructure. См. рисунок 1 ниже.


Рис. 1. Изменение миграции в облако и уровни инвестиций

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

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

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

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

 

Глава 2. Готовность и инвестиционные цели

Оценка технической готовности к облаку

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

  1. Требования к инфраструктуре. Облако отделяет программное обеспечение от базового оборудования и операционной среды. Приложения с высокой степенью зрелости по сути не зависят от своей среды, полагаясь только на общий ресурс инфраструктуры — например, ЦП или кластер Kubernetes — который, в свою очередь, легко масштабируется в облаке. Приложения с низким уровнем зрелости зависят от конкретного оборудования, компонентов или среды, например от управляемой инфраструктуры или иной специализированной системы. Степень жесткой зависимости приложения от компонентов инфраструктуры и конфигураций в облаке должна быть сначала задокументирована, а затем устранена. Нередко можно найти настройки (сделанные вами или вашими клиентами), которые связаны с базовой инфраструктурой.
  2. Компоненты сервисов. Облако дает дополнительные возможности в виде автономных сервисов, работающих и предоставляемых независимо от приложения. Приложения с высокой степенью зрелости построены на основе дискретных компонентов с минимальными зависимостями в стеке, что позволяет вносить целевые изменения и обновления, а также максимизировать время безотказной работы. Архитектура приложений с низким уровнем зрелости состоит из больших, тесно связанных компонентов, которые становятся в значительной степени взаимозависимыми и должны управляться как единое целое. Эти отношения сервисов должны быть задокументированы для каждого приложения.
  3. Операционная готовность. Облако меняет техническую архитектуру, а также рабочие процессы, наборы навыков, доступные инструменты и операционные модели. Приложения с высокой степенью зрелости уже работают как облачные приложения и используют процессы, стандарты и наборы инструментов, которые прекрасно работают в облаке. Приложения с низким уровнем зрелости обнаружат, что критически важные службы поддержки отсутствуют в облаке. У них есть команды, поддерживающие их с неподходящим набором навыков для работы в облаке, или будут использоваться процессы, которые могут быть нарушены при переходе в облако.

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


Zoom быстро масштабируется и активирует миллионы одновременных встреч благодаря Oracle Cloud Infrastructure.

Zoom"Недавно мы испытали самый значительный рост нашего бизнеса в истории компании, что потребовало значительного увеличения объема наших услуг. Мы исследовали несколько платформ, и Oracle Cloud Infrastructure помогла нам быстро расширить наши возможности и удовлетворить потребности наших новых пользователей." —Эрик С. Юань, генеральный директор Zoom

Узнать больше


Финансовые цели

Как и при любой ИТ-инициативе, переход к облаку требует ряда инвестиций для достижения полной отдачи — особенно, если целевое приложение было создано для модели локального хостинга. Приложения, признанные достойными для переноса в облако, со временем станут облачными или будут аннулированы. Однако первоначальной целью обычно является перенос приложения в состояние готовности к облаку.

Все, что требуется для переноса вашего приложения из текущего состояния в состояние готовности к облаку, является результатом ряда решений и первоначальных инвестиций. Планируете ли вы просто «поднять и перенести» приложение на сервер без операционной системы (в таком случае большая часть инвестиций приходится на облачную инфраструктуру) или у вас есть планы сделать приложение готовым к облаку до перехода (потребуются инвестиции для переноса частей стека приложений в облачную модель), например, перенос базы данных из локальной базы данных в DBaaS или Oracle Autonomous Database? Если вы создали жестко запрограммированные настройки для обеспечения возможностей конкретного клиента, их необходимо будет реорганизовать для модели, в которой компоненты платформы инкапсулируются и доставляются через API как производимые функции. Зависимости оборудования или платформы необходимо будет удалить, чтобы масштабировать высокораспределенное приложение в облаке. Понимание этих инвестиций является критически важным фактором для планирования и достижения финансовых целей, связанных с переходом на облако.

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

  • Инвестиции в разработку. Труд разработчиков, необходимый для реорганизации продукта или создания ускорителей миграции, включая автоматизацию для поддержки таких действий, как перенос базы данных и подготовка приложений.
  • Выполнение переноса. Трудовые ресурсы, необходимые для предоставления новых активов, переноса существующих сред и данных, а также вывода из эксплуатации устаревших ресурсов.
  • Обновление инфраструктуры. Плата за подписку, начисляемая через IaaS, которая перейдет в стабильное состояние, но представляет собой новый рост в течение периода миграции.
  • Устаревшая инфраструктура. Постоянные затраты на информационный центр и амортизацию накапливаются в процессе миграции до тех пор, пока они не будут устранены или списаны.
  • Переход рабочей силы. Расходы, связанные с обучением или реструктуризацией существующих команд или приобретением новых ресурсов с необходимыми навыками в облачной среде.
  • Переход клиентов. Затраты, связанные с изменениями экологических характеристик или условий обслуживания, которые не могут поддерживаться в новой модели, включая новые разработки, поощрение, пересмотр условий контракта или уход клиентов

В большей или меньшей степени каждый из этих расходов является необходимым компонентом перехода к IaaS. Каждый по-разному влияет на ваш профиль затрат. Например, расходы на разработку и выполнение миграции могут относиться к разовым — даже если ресурсы, связанные с этой работой, могут быть постоянными. Обновление инфраструктуры приведет к чистому увеличению расходов на период времени, пока не будут устранены неокупаемые расходы на инфраструктуру. Некоторые расходы на переход персонала и клиентов, такие как обучение или поощрение за миграцию, будут представлять собой единовременные расходы. Другие, такие как расширение штата сотрудников или изменение контрактов с клиентами, потенциально могут привести к новым постоянным расходам.

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

Инвентаризация миграции в облако

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

Основная цель инвентаризации миграции — создать централизованное представление о факторах, необходимых для управления переходом в облако. Пример: что такое актив? Где находится актив? Какой продукт он поддерживает? В чем его цель? Каких клиентов он поддерживает?

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

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

Рекомендуем следующую структуру инвентаризации миграции в качестве отправной точки для перехода в облако.

Инвентаризация миграции и операционная инвентраизация

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

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

Глава 3. Начало пути к облаку

Поиск пути к облаку

Проектирование инфраструктуры для размещения SaaS-приложений

Как независимому разработчику программного обеспечения, предоставляющему приложения на основе SaaS, вам необходима безопасная, масштабируемая инфраструктура корпоративного уровня для размещения ваших сервисов и изолированного управления клиентами. Эталонная архитектура, изображенная на рисунке 3 ниже, представляет собой проверенную структуру, которая включает в себя лучшие практики и позволяет размещать свои SaaS-приложения в Oracle Cloud Infrastructure.

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

Вы можете создать все экземпляры приложения клиента из единой базы кода или предложить индивидуализированные версии приложения каждому клиенту. Такой шаблон идеально подходит для клиентов SaaS, которым требуется полная изоляция среды приложения.

Рис. 3. Эталонная архитектура лучших практик для SaaS-приложений на OCI

Для получения дополнительных сведений о приведенной выше эталонной архитектуре см. раздел Oracle Architecture Center. Кроме того, мы создали инструменты на основе Terraform, чтобы помочь в развертывании архитектуры для четырех клиентов, а также пошаговое руководство. Наконец, мы настоятельно рекомендуем изучить Руководство по лучшим практикам Oracle Cloud Infrastructure, которое содержит рекомендации по четырем общим бизнес-целям: безопасность и соответствие, надежность и отказоустойчивость, производительность и оптимизация расходов, а также операционная эффективность.

Помимо изменений в архитектуре, вам стоит подумать о том, как изменится стек ваших сервисов в облаке. Наборы основных инструментов, используемых для мониторинга, управления сетью или безопасности, развернутые в устаревших средах, разработанных для локальных архитектур, будут изменены для облака. Переход в облако дает возможность расширить область применения таких инструментов. Вместо мониторинга конечных точек облачные инструменты предлагают мониторинг всего стека. Иногда поставщик облачных услуг предлагает облачные или гибридные инструменты мониторинга помимо основных возможностей. В случае Oracle Cloud Infrastructure сочетание встроенных возможностей мониторинга, тегирования и аудита обеспечивает возможность мониторинга всего стека сервисов и часто автоматически устраняет отклонения, обнаруженные за пределами установленных норм. Если сейчас вы используете сторонние локальные инструменты мониторинга, эти поставщики также могут предложить гибридные или облачные инструменты.


Cisco Tetration переносит свое базовое приложение в Oracle Cloud Infrastructure, увеличив производительность в 60 раз.

Cisco Tetration" Партнерство с Oracle — это фантастика. Именно благодаря им Cisco Tetration претерпевает волшебные изменения." —Навиндра Ядав, основатель Cisco Tetration


Поддержка вашей пилотной программы

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

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

Пилотные проекты дают следующие преимущества:

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

Компания Manhattan Associates переносит свои решения для управления материальными потоками в Oracle Cloud Infrastructure, сократив расходы на 50% по сравнению с предыдущим облачным решением.

Manhattan Associates"Универсальность и гибкость Oracle Cloud как на уровне приложений, так и на уровне базы данных позволили сэкономить около 50% по сравнению с нашими предыдущими облачными решениями с точки зрения инфраструктуры." —Джефф Деменков, вице-президент Manhattan Associates


Управление пилотной программой

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

  • Обучение. Пилотные проекты проверяют существующие навыки, показывая, насколько организация подготовлена к работе по технической миграции. Руководству следует использовать пилотный проект для оценки технической квалификации, понимания того, какие инструменты и возможности наиболее важно изучить, и спланировать, как быстро развить навыки (или нанять специалистов) в этих ключевых областях.
  • Совместная работа. Пилотные проекты показывают, как группы разработки, эксплуатации и поддержки будут работать вместе. Руководство обязано удостовериться, что эти команды действительно работают вместе во время пилотного проекта, выявляя новые требования и формируя понимание того, как действовать в этой новой среде.
  • Жажда перемен. Пилотные проекты — это возможность найти культурные барьеры, которые повлияют на более масштабную миграцию. Группа, у которой возникают проблемы с пилотным проектом, столкнется с теми же проблемами при более масштабной миграции. Пилотный проект — это возможность для руководства выявить проблемы, развернуть обучение и скорректировать планы с учетом реалий своей конкретной организации.

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

Глава 4. Облачные организационные результаты

Адаптация к организационным изменениям

Проектирование инфраструктуры для размещения SaaS-приложений

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

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

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


8x8 поддерживает связь во всем мире, снижает расходы на 80% и улучшает качество обслуживания за счет перехода на Oracle Cloud Infrastructure.

8x8" По мере того, как видеовстречи быстро стали необходимостью в современном мире, количество наших пользователей резко возросло. Чтобы поддержать этот экспоненциальный рост, мы рассмотрели несколько платформ и выбрали инфраструктуру Oracle Gen 2 Cloud за ее надежную безопасность, отличное соотношение цены и качества и поддержку мирового класса для обслуживания этого нового всплеска пользователей." —Вик Верма, генеральный директор 8x8

Смотреть видео


Последствия для бизнеса

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

Даже в сценариях с минимальными изменениями переход на IaaS приведет к сдвигам в бизнес-процессах. Наши подразделения определили две ключевые возможности для изменений в этом контексте.

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

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

Ориентация на клиента

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

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

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

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

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


CMIC переносит свое корпоративное программное обеспечение для строительства на Oracle Cloud Infrastructure при скорости развертывания в 10 раз выше.

CMIC"Помимо преимуществ OCI в затратах по сравнению с другими поставщиками облачных услуг, мы отметили повышение гибкости нашей системы. OCI предоставляет нам новый уровень технологической гибкости. Мы идем в будущее с такими технологиями, как Oracle Container Services и Oracle Autonomous Database, чтобы мы могли и далее сосредотачиваться на предоставлении самого лучшего доступного программного обеспечения ERP для строительства." —Винс Ди Пьяцца, директор по ИТ и облачной инфраструктуре, CMIC

Смотреть видео


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

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

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

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

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

Глава 5. Пять основных проблем

Предварительная подготовка

Проектирование инфраструктуры для размещения SaaS-приложений

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

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

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

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

    Чтобы решить эту проблему, глобальные подразделения полагались на структуры зрелости облака, описанные в главе 1. Именно они позволили получить представление об относительных инвестициях в разработку, необходимых для каждого пути. Затем они изучили рентабельность инвестиций на каждом этапе потенциального перехода к облаку и сопоставили этот результат с потенциальным доходом, ожидаемым от разработки новых функций. Это обеспечило общую структуру оценки, которую можно было использовать для определения правильного сочетания усилий и обеспечения видимости желаемых бизнес-результатов.
    Altair выбирает высокопроизводительные вычисления Oracle Cloud Infrastructure и повышает соотношение цены и качества на 20%.

    Altair"Мы изучили предложения всех поставщиков облачных услуг и обнаружили, что решения Oracle основаны на высокопроизводительных вычислениях. Их предложение без операционной системы, которое, насколько мне известно, было первым таким предложением в отрасли, отличалось высокоскоростными сетями с минимальной задержкой, что очень важно для нас." —Пиуш Патель, старший вице-президент по стратегическим отношениям, Altair


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

    В отношении каждого экземпляра приложения требуются различные типы и объемы работы в зависимости от характеристик экземпляра (версия, зависимости оборудования / платформы, настройки, модель клиентского доступа и т. д.). Кроме того, данные приложения могут быть распределены по нескольким системам записи.

    Глобальные подразделения Oracle — это объединение более 30 организаций, под управлением которых работают 80 информационных центров и более 12 000 экземпляров приложений. Важные данные, относящиеся к таким экземплярам, были сильно фрагментированы и не всегда управлялись единообразно разными командами по компонентам продуктов. Без этой информации они не могли бы эффективно организовать и спланировать трудовые ресурсы, необходимые для миграции. Чтобы получить четкое представление о том, что необходимо перенести, глобальным подразделениям пришлось провести специальный сбор и консолидацию данных.

    "Команда глобальных подразделений Oracle смогла снизить капитальные затраты на 80% и снизить затраты на инфраструктуру на 64% за счет перехода на OCI." —Майк Приндл, вице-президент по облачной архитектуре глобального подразделения
    Oracle@Oracle


  4. Расстановка приоритетов и организация усилий по миграции
    Фактический перенос рабочих нагрузок может производиться разными способами: от копирования образов существующих виртуальных машин до установки нового экземпляра и репликации данных. Однако все они требуют определенного уровня технических вложений или трудозатрат для завершения. Количество и виды рабочей силы, вовлеченной в миграцию, умножается на каждую продуктовую среду в портфеле организации. Ресурсы, доступные для завершения переноса, ограничены и часто также отвечают за управление повседневными операциями.
    OceanX переносит свои системы бизнес-аналитики на Oracle Cloud Infrastructure с Amazon Web Services (AWS), повысив производительность в 3 раза.

    OceanX"Нам нужна была платформа данных, которую можно было бы масштабировать при обеспечении высокой производительности и низких расходах. Миграция платформы данных с AWS на Oracle была одной из самых успешных в OceanX, и в сочетании со значительным увеличением производительности и значительной экономией средств вся программа имела оглушительный успех. В конечном итоге это позволяет нам предоставлять клиентам платформу, которая помогает им быстрее принимать более обоснованные решения." — Виджей Маникам, вице-президент по данным и аналитике OceanX


    Для перехода к облаку глобальным подразделениям потребовалось более 3000 отдельных проектов миграции. Первоначально для этих проектов были расставлены приоритеты на основе предпочтений клиентов (т. е. приоритизация сроков миграции на основе сводных отзывов клиентов) или готовности к миграции конкретной среды. В конечном итоге этот подход не помог получить дополнительные бизнес-преимущества в ходе миграции. Без общей системы приоритетов или координации глобальные подразделения наблюдали непоследовательный объем миграционной активности. Это обременило команды, ответственные за завершение работ по миграции, чередующимися периодами высокой конкуренции за ресурсы и напрасной доступности ресурсов.

    Чтобы решить эти проблемы, глобальные подразделения создали центральный офис управления программой, посвященный миграции, а также исполнительный комитет по надзору, отвечающий за приоритеты миграции по сравнению с желательными бизнес-результатами и определение основных возможностей.
  5. Управление организационными изменениями
    Изменения, связанные с переходом в облако, требуют новых областей знаний, навыков и процессов, а также иных культурных изменений. Управлять этими кадровыми проблемами может быть сложнее, чем техническими аспектами перехода к облаку. Чтобы решить эту проблему, глобальные подразделения Oracle помогли существующим командам превратиться в облачные команды, сосредоточив внимание на обучении. Решение вопроса о том, когда привлекать новые кадры, а когда искать механизмы для дальнейшего развития организации, требовало, чтобы глобальные подразделения проводили оценку персонала по своим основным функциональным областям и группам продуктов, а затем отображали соответствующие инициативы по улучшению для каждого варианта использования. Если вашей компании необходимо перенести несколько приложений, подумайте, где можно создать базовые облачные знания, которые охватывают все продукты, например безопасность и IaaS.

Глава 6. Результаты и начало работы

Празднование результатов

Данное руководство основано на опыте, накопленном командами глобальных подразделений Oracle при миграции более 60 SaaS-приложений в Oracle Cloud Infrastructure. Данные приложения поддерживают основные корпоративные функции в восьми отраслевых вертикалях и позволяют обслуживать более 199 000 клиентов по всему миру. Тщательная, спланированная и качественно выполненная миграция принесла существенные преимущества.

  • 80 информационных центров объединены в 11
  • Капитальные затраты снижены на 80%
  • Расходы на инфраструктуру снижены на 64%
  • Количество разработчиков программного обеспечения снижено с 28 до 10
  • Расходы на ПО снижены на 42%
  • Осуществляются ежедневные выпуски ПО
  • Время инициализации снижено более, чем на 98%
  • Запланированное время простоя снижено более, чем на 98%

Хотя данное руководство для независимых разработчиков программного обеспечения основано на опыте, накопленном командами наших глобальных подразделений, их усилия были лишь одним из нескольких крупных переходов на Oracle Cloud Infrastructure. Принимая во внимание доходы и количество клиентов по всем нашим приложениям SaaS, Oracle можно рассматривать как одного из крупнейших независимых разработчиков программного обеспечения в мире, и мы понимаем, что представляет собой процесс миграции. Мы осуществили перенос всего нашего портфеля продуктов, включая Oracle Fusion Cloud ERP, Oracle Fusion Cloud EPM, Oracle Fusion Cloud HCM, Oracle Advertising and CX и Oracle Fusion Cloud SCM в Oracle Cloud Infrastructure. Эти переносы являются частью нашей инициативы по преобразованию, которую мы называем Oracle@Oracle. Это многолетний проект, в котором были задействованы десятки тысяч приложений, размещенных в десятках информационных центров.

Вот несколько преимуществ, которые мы наблюдали в результате.

  • Инфраструктура – достигнута доступность 99,99% для всего нашего портфеля приложений при снижении расходов на 30% и повышении производительности в 2–10 раз
  • Финансы – получена возможность подводить итоги и сообщать о доходах менее, чем за 10 дней.
  • Кадры – продолжительность цикла проверки кадров сокращена на 70%
  • Управление материальными потоками – сокращение цикла планирования материальных потоков с 1 недели до 48 часов — при улучшении на 71%
  • CX – время выполнения кампании сокращено с 4 недель до 5 дней — при улучшении на 82%
  • Экологичность – повторно использовано или переработано 99,4% списанного оборудования, собранного в Oracle в 2019 финансовом году

Партнерство с Oracle

Мы помогаем независимым разработчикам программного обеспечения расширять свой адресный рынок, увеличивая при этом их потенциал роста доходов. Отправьте нам электронное письмо по адресу: oraclecloud-isv_ww@oracle.com, если хотите узнать подробности.

Чтобы узнать больше о том, почему независимые разработчики программного обеспечения выбирают Oracle Cloud, см. следующие ресурсы:


Körber объединяет системы управления складом в Oracle Cloud Infrastructure, ускорив работу на 40%.

Korber" Когда мы оценивали различные решения, мы осознали, что OCI идеально подходит для нашей стратегии выхода на рынок." — Рик Шрейдер, старший вице-президент по продажам и альянсам в Северной Америке, Körberö

Смотреть видео