Готова ли корпоративная ИТ-архитектура к работе в облаке? Готово ли облако к размещению корпоративной ИТ-архитектуры? Облачные технологии представляют собой другой способ мышления. Но мы уже сталкивались с этим ранее.
В своем новом посте Крис Бруцци и Ник Хэмм, сотрудники компании Appirio, занимающейся предоставлением облачных услуг, делятся своим опытом создания облачных приложений. Они указывают на пять изменений в подходе к этой работе, которые необходимо внедрить по мере того, как разработка приложений и сами приложения приспосабливаются к миру облачных технологий.
Для архитекторов и разработчиков, уже имевших опыт обращения с сервисно-ориентированной архитектурой, большинство этих рекомендаций из разряда best practice покажутся удивительно знакомыми. Но Бруцци и Хэмм отмечают, что архитектура SOA в прошлом была более ограниченной, поскольку обычно она заканчивалась на границе корпоративной сети. Сейчас, по мере того как ИТ всё больше и больше начинают “подсаживаться” на облачные технологии, настало время на деле продвинуть “сервисно-ориентированное мышление”:
1. Проектируйте решение в виде набора компонентов. “Отойдите в сторонку и подумайте о бизнес-требованиях, а затем предложите решение в виде набора слабо связанных между собой компонентов, отвечающего общим требованиям. Это обычно требует не намного большей предварительной работы, но приносит более высокие дивиденды в дальнейшем”.
2. Используйте интерфейсы прикладного программирования (API) вместо языков программирования. Десять лет назад ИТ-организации делились на сторонников либо Java-, либо .NET-приложений. Облачный подход переносит фокус с приложений, тесно привязанных к языкам и платформам, на предоставление сервисов, считают Бруцци и Хэмм. “Для вас как архитектора облачных решений это означает необходимость переноса фокуса вашего внимания с технологий и языков на проектирование сервисов и на API, необходимые для доступа к ним”.
3. Применяйте по максимуму повторное использование компонентов. Компоненты, включенные в проект облачного решения, могут быть уже кем-то полностью разработаны и существовать либо в собственной библиотеке организации, либо у внешних провайдеров облачных услуг — таких, как Salesforce.com или Amazon Web Services.
4. Увеличьте свою команду с помощью методики краудсорсинга. Обратитесь к сообществам разработчиков, например CloudSpokes или 99Designs, за новыми компонентами. “Преимущество этого подхода в том, что вы можете разрабатывать бóльшую часть своих приложений быстро и параллельно, поскольку вы не ограничены возможностями собственной команды. Вас также могут сильно удивить творческие решения, о которых вы даже не думали”.
5. Измеряйте свои приложения. “Облачные решения предлагают огромную, доступную для обработки массу данных о таких аспектах вашего приложения, как конфигурация, код, качество и т. д., — указывают Бруцци и Хэмм. — Некоторые облачные провайдеры собирают эти метрики, но не все так поступают, так что, возможно, вам придется побегать”.
