Архітектор повинен розбиратися в обладнанні

Камал Вікраманаяке

Для багатьох архітекторів тема планування потужностей обладнання виходить за рамки їх «зони комфорту», ​​проте вона залишається важливою частиною роботи архітектора Причини, з яких архітектори часто забувають приділити належну увагу обладнанню, досить різноманітні, але всі вони повязані здебільшого з непорозумінням і нечіткістю вимог

Головна причина полягає в тому, що ми повністю концентруємося на програмній осторонь і ігноруємо апаратні вимоги Вдобавок мови високого рівня і програмні інфраструктури (software frameworks) природним чином ізолюють нас від устаткування

Істотним фактором є і нечіткі вимоги, оскільки вони можуть бути неправильно зрозуміли або піддані значним змінам У міру розвитку архітектури її апаратні аспекти теж змінюються До того ж може виявитися, що клієнт не усвідомлює або не може оцінити розмір контингенту користувачів або спрогнозувати динаміку використання системи Нарешті, обладнання постійно вдосконалюється Те, що ми знаємо про нього з минулого досвіду, може бути неактуальним сьогодні

Без знання обладнання прогнозування апаратної конфігурації розроблюваних систем – заняття надзвичайно ненадійне Як компенсацію деякі архітектори використовують великі значення запасу продуктивності, які зазвичай не спираються на будь-які обєктивні оцінки або методологічні рекомендації У більшості випадків це призводить до надлишкової продуктивності обладнання, яка не буде задіяна навіть у періоди пікового навантаження У результаті гроші клієнта витрачаються на обладнання більш потужне, ніж реально необхідно системі

Найкращий захист від неякісного апаратного планування – тісна взаємодія з архітектором апаратної інфраструктури На відміну від архітекторів програмного забезпечення, архітектори апаратної інфраструктури добре розбираються в плануванні обчислювальних потужностей вони повинні бути частиною вашої команди Втім, не кожному архітектору програмного забезпечення доступна така розкіш, як можливість працювати з архітектором апаратної інфраструктури У таких випадках архітектор системи може прийняти деякі заходи, які знижують ймовірність помилок при плануванні обладнання

Наприклад, вам може стати в нагоді минулий досвід Якщо ви колись уже займалися реалізацією систем, то у вас є деяке уявлення про планування апаратної потужності – хоча б на підставі ретроспективного аналізу Ви можете також обговорити цю тему зі своїм клієнтом і переконати його виділити кошти на планування потужності обладнання Фінансування такої діяльності часто виявляється набагато вигідніше покупки устаткування понад реально необхідного У цьому випадку ключова роль відводиться горизонтальній масштабованості1: Обладнання додається у міру потреби замість надлишкових закупівель на самому початку Щоб «горизонтальна стратегія» працювала, архітектор ПО повинен постійно проводити вимірювання обчислювальної потужності і ізолювати програмні компоненти для запуску в середовищі з прогнозованими показниками продуктивності

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

Камал Вікраманаяке (Kamal Wickramanayake) – архітектор апаратного та програмного забезпечення, живе на Шрі-Ланці Є володарем сертифікату TOGAF від The ​​Open Group

Горизонтальна масштабованість – розбиття системи на більш дрібні структурні компоненти та рознесення їх по окремим фізичним машинам або збільшення кількості серверів, паралельно виконують одну і ту ж функцію Вертикальна масштабованість – збільшення продуктивності кожного компонента системи з метою підвищення загальної продуктивності (Див http://ruwikipediaorg/wiki/Масштабируемость) – Прямуючи ред

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*