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

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

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

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

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

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

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

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

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

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

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

Авторские права © 2021 IDG Communications, Inc.


#ошибки #мультиоблачной #архитектуры #InfoWorld

Source link