Марку Андрессену принадлежит знаменитая фраза «программное обеспечение пожирает мир». И он прав: все шире используя возможности облачных вычислений и распределенной сети датчиков, именуемой Интернетом вещей – мы придем к миру, кардинально отличающемуся от сегодняшнего. Не так просто представить, что даст миру появление нового программного уровня из умных устройств.
Все великое начинается с малого, и нам еще только предстоит разобраться, как мы будем строить этот дивный новый мир. Начинать с малого достаточно просто, поскольку программное обеспечение будущего будет основываться на сегодняшних принципах и методиках разработки. Одной из основополагающих технологий, вероятно, станет микросервисная архитектура, предложенная рядом авторитетных консультационных фирм.
Если посмотреть правде в глаза, то микросервисы представляют собой лишь другой подход к давней идее о сервис-ориентированной архитектуре (СОА). Это хорошо, поскольку технология СОА, хоть и не добилась выдающихся показателей, была многообещающей. Теперь произошел возврат к данной перспективной идее о проектировании приложений в качестве группы сервисов с четко определенным программным интерфейсом. Такой подход особенно актуален в рамках модели постоянной поставки.
Для небольших комплексных команд разработчиков предоставление микросервисов включает разработку, тестирование и запуск. Именно по такой модели работает профессиональное движение DevOps, которое выступает за совместные рабочие отношения между разработчиками и ИТ-подразделением. Не удивительно, что в основе обоих подходов лежат принципы гибкой разработки. Достаточно взглянуть на Amazon или Facebook с их отдельными командами разработчиков, сосредоточенными каждая на определенном сервисе, которые затем объединяются на сайте. В результате получается многоцелевое приложение, которое отвечает потребностям каждого отдельно взятого пользователя. Трудно отыскать две одинаковых по функционалу пользовательские страницы.
Как и в любом хорошем СОА-дизайне, сервисы на моей странице размещаются и соединяются модулем управления, который забирает данные из одного набора сервисов для отображения в другом. Именно здесь на первый план выходят программные интерфейсы, поскольку именно они определяют, как данные сервиса запрашиваются, передаются, обрабатываются и отображаются.
Если вы планируете строить свое приложение вокруг микросервисов, то следует убедиться, что все программные интерфейсы, предоставляемые сервисами, четко определены, документированы и, что важнее всего, неизменны. Конечно, это не означает, что вы не можете выпускать новые версии программных интерфейсов или помечать часть из них, как «устаревшие». Но пока какой-либо другой сервис использует данный программный интерфейс, его нельзя изменять. Компания Lego не меняет размеры своих деталей, и похожий подход должен быть реализован в ваших программных интерфейсах.
Лучше всего программные интерфейсы представлять в качестве договоров. Подобно юридическому документу, они в полной мере определяют взаимодействие двух единиц программного обеспечения. После того, как договор заключен, он не может быть нарушен без взаимного соглашения или судебного постановления. Именно по этой причине важно внедрить стандарты программного управления перед переходом к микросервисной или другой интерфейсной архитектуре.
Стандарты управления образуют структуру, позволяющую выносить решение о дальнейшей судьбе программного интерфейса. Допустим, текущая версия программного интерфейса перегружает центральный процессор, или какую-то важную часть программного кода не успевают привести в соответствие к объявленной дате вывода из эксплуатации. На встрече группы управления представители обеих сторон могут представить на суд свои аргументы и договориться о дальнейшей работе данного программного интерфейса.
При сервисном подходе управление программными интерфейсами становится задачей первостепенной важности, особенно если они могут использоваться для своих приложений разными командами разработчиков в рамках одной организации. После публикации программного интерфейса, он всегда должен быть готов к использованию. Это означает, что вам понадобятся средства контроля. Будете ли вы использовать готовые инструменты, к примеру от компании Apigee, добавляющие уровень управления программными интерфейсами? Или самостоятельно разработаете необходимые вам средства аутентификации и управления?
Использование специализированных инструментов управления сервисами и программными интерфейсами целесообразнее собственных решений. Они разработаны для подключения к каталогам предприятия в рамках упрощенной аутентификации, предоставляют возможность динамически контролировать доступ к программным интерфейсам в зависимости от пользовательских ролей и даже предлагают дополнительные возможности различным категориям пользователей. Обладая хорошим уровнем управления, вы можете разрабатывать программные интерфейсы с полной поддержкой всех возможностей, а затем настроить и ограничить доступ, как посчитаете нужным.
Данные программные интерфейсы не обязательно должны размещаться на сервере, персональных компьютерах или мобильных телефонах. Они могут быть встроены в датчики и открыты для любого взаимодействия. У меня дома на стене висит умная пожарная сигнализация Nest, передающая данные в «облако», к которому я могу получить доступ через сервис IFTTT. Я написал простенький скрипт, отмечающий уровень заряда батареи в облачном сервисе для записей OneNote. Таким образом, объединив программные интерфейсы нескольких независимых микросервисов, я привел Интернет вещей к классическому программному приложению.
Именно это подразумевал Андрессен, говоря о том, что «программное обеспечение пожирает мир» – возможность взаимодействия чего угодно через программное обеспечение. Но поскольку на этот раз мы имеем дело с сервис-ориентированной архитектурой позвольте мне перефразировать Андрессена: программные интерфейсы пожирают мир. Учитывая это, мы можем приступить к созданию необходимых инструментов для мира, работающего на программном обеспечении.
Перевод - Павел Корнилов
Оригинал - http://www.appy-geek.com/Web/ArticleWeb.aspx?regionid=1&articleid=28414756&m=d