Платформа воспринимается сегодня как избитое понятие.
Когда речь заходит о платформах в компьютерном деле, чаще всего имеется в виду набор возможностей, помогающих либо создавать, либо запускать приложения. Лучше всего платформы обобщаются по требованиям, которые предъявляются к способам, используемым разработчиками при создании приложений.
Платформы позволяют автоматизировать решение задач, не играющих существенной роли в поддержке бизнес-требований, предъявляемых к приложению. Это помогает командам разработчиков действовать оперативно, позволяя поддерживать только функциональные компоненты, имеющие особую ценность для делового применения.
Та команда, которая написала сценарии оболочки либо наштамповала контейнеры или виртуальные машины для автоматизации разработки, уже создала своеобразную платформу. Вопрос заключается в следующем: что может дать эта платформа, каким ожиданиям соответствует? Какой объем работы потребуется для поддержки основных (или даже всех) требований для непрерывной поставки нового ПО?
При построении платформ создается инструмент, автоматизирующий набор повторяющихся приемов; последние складываются из набора требований, которые превращают ценные идеи в план.
- Идеи: каковы основные замыслы платформы и в чем их ценность?
- Требования: каковы требования, соблюдение которых необходимо для превращения наших идей в приемы?
- Приемы: как автоматически перевести требования в набор повторяющихся приемов?
В основу любой платформы закладываются простые идеи, которые в случае их реализации повышают дифференцированную деловую ценность за счет использования автоматизированного инструментария.
Возьмем, к примеру, платформу Amazon.com. Вернер Фогельс заявил: «Повышая изолированность компонентов программ друг от друга, команды будут иметь больше возможностей контроля тех функций, которые вводятся ими в производство».
Идея облачной платформы
Повышение изолированности компонентов программ друг от друга позволяет доводить части системы до практического применения независимо и в более сжатые сроки.
Закладывая эту идею в основу платформы, мы получаем возможность сформировать из нее набор требований. Они принимают форму взгляда на то, как основная идея будет воплощена на практике при автоматизации. Следующие утверждения представляют собой категоричные требования к способам повышения изолированности компонентов.
Требования к платформе облачных вычислений
- Компоненты программ должны разрабатываться в виде независимо развертываемых сервисов.
- Вся бизнес-логика в сервисе инкапсулируется с теми данными, с которыми она работает.
- За пределами сервиса не должно быть прямого доступа к базе данных.
- Сервисы должны предоставлять веб-интерфейс для обращения к их бизнес-логике со стороны других сервисов.
На основе этих требований складывается весьма категоричный взгляд на приемы усиления изолированности компонентов программы. Обещания, связанные с выполнением приведенных требований в виде автоматизированных механизмов, сулят командам предоставление более действенного контроля над функциями, поставляемыми для эксплуатации. Следующим шагом станет описание того, как эти требования могут быть сведены к набору повторяющихся приемов.
Приемы, выведенные исходя из этих требований, должны быть заявлены в виде коллекции обещаний. Указывая приемы в виде обещаний, мы задаем ожидания пользователей платформы относительно способов, которые они могут задействовать при создании и эксплуатации своих приложений.
Приемы облачных платформ
- Командам предоставляется интерфейс самообслуживания, позволяющий обеспечить инфраструктуру, требуемую для функционирования приложений.
- Приложения помещаются в пакет, представляющий собой полный комплект, развертываются в среде с помощью интерфейса самообслуживания.
- Базы данных предоставляются приложениям в виде сервиса и должны вводиться в действие с использованием интерфейса самообслуживания.
- Приложение снабжается всем необходимым для регистрации в базе данных в виде переменных среды, но только после объявления явного отношения к базе данных в виде привязки к сервису.
- Каждому приложению предоставляется сервисный реестр, применяемый в качестве манифеста местоположений внешних сервисных зависимостей.
Каждый из вышеперечисленных приемов принимает форму обещания для пользователя. Таким образом, суть идей, закладываемых в основу платформы, реализуется в виде требований, предъявляемых к приложениям.
В основе приложений, оптимизированных для работы в облачной среде, лежит набор требований, позволяющих сократить время, затрачиваемое на однообразную трудоемкую деятельность.
Когда технология AWS была впервые представлена публике, Amazon не заставляла ее пользователей придерживаться тех же требований, которые применялись в самой компании. Оставаясь верным своему названию Amazon Web Services, сама по себе технология AWS не является облачной платформой, а представляет собой коллекцию независимых инфраструктурных сервисов, из которых может быть составлена автоматическая оснастка, напоминающая платформу обещаний. Спустя годы после первого выпуска AWS компания Amazon начала предлагать коллекцию управляемых сервисов платформы с вариантами использования, начиная от Интернета вещей (IoT, Internet of Things) и заканчивая машинным самообучением.
Если какой-либо компании понадобится создать свою собственную платформу с нуля, время поставки приложений откладывается до полной сборки платформы. Компании, ставшие ранними пользователями AWS, должны были вместе собрать некую разновидность автоматизации, похожую на платформу. Каждой компании пришлось бы выработать набор обещаний, охватывающих основные идеи создания и ввода ПО в эксплуатацию.
Совсем недавно производство ПО ориентировалось на идею существования основного набора общих обещаний, исполняемых каждой облачной платформой. Эти обещания будут исследоваться в моем блоге с применением платформы в виде сервиса (Platform as a Service, PaaS) под названием Cloud Foundry. Основным предназначением последней является предоставление платформы, вбирающей в себя набор общих обещаний, касающихся быстрой разработки и применения приложений. Cloud Foundry дает эти обещания, одновременно сохраняя возможность переносимости между облачными инфраструктурами нескольких различных поставщиков.
