Что будет дальше с инфраструктурными вычислениями после контейнеров и бессерверных вычислений

Десять лет назад развертывание среды разработки было отстойным.

Heroku и AWS были в зачаточном состоянии, относились к тому специальному набору инструментов для разработчиков, который лучше оставить людям с бородой, которые слушали Интерпол и пили только проливной кофе. Большая часть мира по-прежнему полагалась на colos-c удаленные вычислительные центры, где вы арендовали необработанный физический сервер или виртуальную машину, работающую в удаленном управляемом центре обработки данных.

Это означало, что развертывание приложения было длительным и болезненным процессом. Сначала мне нужно установить на машине операционную систему, обычно развертываемую с помощью образа диска. В то время Vagrant не существовало, поэтому даже если бы образ диска содержал несколько приложений и библиотек, мне все равно пришлось бы мучительно «связать» все вместе после успешной установки образа. Где-то по ходу дела мне также нужно было бы выяснить, как правильно (и в идеале безопасно) сделать эту машину доступной для Интернета, чтобы она могла обслуживать запросы вне меня, входя в систему как root.

В основном это отстой.

Тем не менее, это было лучше, чем было за пять лет до этого. Виртуализация резко снизила стоимость вычислений, позволив небольшим командам и отдельным разработчикам фактически сдавать в аренду инфраструктуру, тогда как раньше вам пришлось бы сдавать в аренду полный цветной ящик. VMWare заслужила свою многомиллиардную оценку за свою работу над ESX, а тройка гипервизоров - ESX, Microsoft Hyper-V и FOSS Linux KVM - позволила снизить стоимость эксплуатации среды разработки до поразительно низкого уровня.

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

За последнее десятилетие мы объединили виртуализацию с абстракцией для решения этих проблем. Сегодня инфраструктура приложений становится все более динамичной. Вместо того, чтобы полагаться на виртуальную машину или сервер с полной подсветкой и машину Руба Голдберга личных скриптов для развертывания приложения, я могу быстро развернуть контейнер Kubernetes и заставить Chef, Puppet или Terraform связать все вместе и получить онлайн часть работы. Бессерверные вычисления также быстро приближаются к горизонту, обещая возможность развертывать некоторые вычислительные задания, не беспокоясь об инфраструктуре.

Несмотря на эти грандиозные достижения в области инфраструктуры, мы все еще довольно далеки от решения трех наших ключевых проблем:

  • Удешевление вычислений
  • Упрощение и безопасность изолированного развертывания приложений
  • Упрощение автоматической настройки инфраструктуры приложений

Вам все еще нужно знать, как использовать инструменты в Terraform. Вам все еще нужно знать, как настроить Kubernetes и Nomad. А в случае бессерверной инфраструктуры, растущего сектора инфраструктуры, который до странности увлечен функциональным программированием (я пристально смотрю на вас, хипстерские хакеры), вам необходимо приобрести определенный стиль программирования, чтобы использовать его должным образом. Cегодня.

Атомные вычисления: решение трех ключевых проблем

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

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

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

В физике и химии это стало пониманием того, как атомы и молекулы реагируют на поведение, которое мы наблюдаем без микроскопов. Затем, когда мы создали квантовую теорию, выяснили, как субатомные частицы способствуют наблюдаемому нами поведению атомов.

В инфраструктуре структуры абстракции, которые нам необходимо обнаружить, направлены на упрощение работы разработчика в отношении трех ключевых проблем.

Успешный переход от виртуальных машин к контейнерам означал, что нам нужно / нужно выяснить, как приложения подготавливаются, объединяются вместе и, в конечном итоге, дешевле и проще в развертывании с учетом текущего состояния мира разработчиков. Успешный переход «на один уровень вниз» от инфраструктуры, ориентированной на контейнеры, к атомарным бессерверным модулям означает, что нам нужно ответить на те же вопросы: как мы можем упростить процесс развертывания нового атомарного модуля, его настройки и предоставления его разработчикам дешевле с учетом их текущих способ предоставления инфраструктуры.

Обнаружение нашего броуновского движения

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

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

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

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

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

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

Лучшая гиперпоточность: удешевление вычислений

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

Одна область, в которой, как я полагаю, есть значительно неиспользованный набор технологий, - это многопоточность. Многопоточность - это процесс распределения вычислительной задачи на несколько вычислительных ядер. За последние 20 лет было необходимо выяснить, как разделить и победить различные подзадачи вычислительной задачи, поскольку закон Мура начал замедляться, а многопоточность сегодня уже используется в ряде приложений с высокой производительность вычислений для майнинга биткойнов.

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

Это не технологическая проблема. Это культурная проблема. Нам нужно новое поколение разработчиков, которые изначально «выросли» на многопоточном программировании, чтобы продвигать новые вычислительные среды, которые поддерживают многопоточность и делают ее более простой и распространяемой.

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

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

Криптографическая изоляция и улучшенная подготовка: упрощение и безопасность развертывания

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

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

Но это также означает, что мне нужно потратить значительное количество времени и усилий на «предварительную работу» перед выполнением этой работы. Мне нужно подумать о сложности других вспомогательных приложений для предоставления переменных экземпляра и данных лямбда-заданию. Мне нужно выяснить точный порядок, в котором это задание будет выполняться по отношению к этим другим вспомогательным приложениям или службам, поскольку бессерверный форм-фактор неудивительно спартанский. И если я использую другие сервисы AWS, такие как RDS, мне нужно, чтобы моя лямбда-функция работала в том же регионе, что подчеркивает, что за кулисами существует какая-то проблема с географическими данными, которая гарантирует, что самая большая в мире бессерверная платформа на самом деле не работает. настолько динамично, насколько мы могли бы подумать за кулисами.

Также зачем мне писать лямбда-функцию? Я не понимаю, почему мы решили полагаться исключительно на одну парадигму программирования для определения форм-факторов бессерверных вычислений. Да, как человек, которого тоже заставили (под дулом пистолета) изучить Схему, я понимаю ценность функционального программирования для распределенных вычислений. Но в мире, где мы пытаемся привлечь следующее, нынешнее поколение разработчиков к следующему важному этапу развития инфраструктуры с помощью разнообразных и доступных языков программирования, таких как Python, не следует ли нам аналогичным образом продвигать парадигмы нефункционального программирования. которые обычно используются на этих языках?

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

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

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

Если следующее вычислительное устройство сможет внедрить надежную, устойчивую к взлому криптографию на обоих этапах, это само по себе обеспечит сильный casus belli для перехода к этой новой атомарной архитектуре.

Интеллектуальное планирование: упрощение настройки

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

Мы снова можем взглянуть на текущее состояние AWS Lambda, чтобы понять, почему эта проблема так важна. После того, как я настроил свою машину Руба Голдберга для запуска моей лямбда-инфраструктуры, если я что-то изменю в этой инфраструктуре, это создаст значительную (и потенциально очень неприятную) проблему обеспечения правильного выполнения задания. Поскольку мир инфраструктуры становится все более динамичным и многооблачным, изменения в моей инфраструктуре почти гарантированы.

Следующий модуль атомарных вычислений должен решить эту проблему, предоставив более элегантный механизм работы с планировщиком для адаптации к изменениям инфраструктуры. Это не то, что компьютеры могут / должны делать сами по себе. Вместо этого нам нужно убедиться, что существует кодифицированный способ работы планировщика (ов) следующего поколения с этим вычислительным блоком, чтобы полностью абстрагироваться от «примитивов» того, как этот блок работает - его хранилища, его сетевой конфигурации и т. Д.

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

Будущее за атомом

Тьюринг был прав. Мы действительно не знаем, что ждет виртуализацию и атомные вычисления.

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