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

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

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

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

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

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

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

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

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

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

No Comments