08.08.22 14:16

Новости

Автор:

Администратор

Не перегружайте свою облачную архитектуру

 Слишком много людей разрабатывают облачную архитектуру, которая является классной, но слишком сложной. Самые успешные архитекторы используют концепцию KISS («Keep it simple,...

Слишком много людей разрабатывают облачную архитектуру, которая является классной, но слишком сложной. Самые успешные архитекторы используют концепцию KISS («Keep it simple, stupid») и делают ее простой!


Автор: Дэвид Линтикум, InfoWorld 

 

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

 

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

 

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

 

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

 

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

 

Если вы спросите инженеров, почему они разработали решение именно таким образом (независимо от того, было ли оно перепроектировано или нет), они будут защищать свой подход по какой-то причине или цели, которые никто, кроме них, не понимает. Когда вы переходите к базовой облачной архитектуре – или любому дизайну решения, если уж на то пошло, – все сводится к мнению и предвзятости. Более того, многие инженеры утверждают, что пока это работает, кого волнует, как оно было спроектировано?

 

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

 

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

 

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

 

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

 

Хорошо, теперь, когда мы знаем о проблеме, возможно, даже согласны с тем, что это проблема, что нам с этим делать?

 

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

 

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

 

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

 

Ссылка на источник