Это будущее

в 20:29, , рубрики: ит-инфраструктура, облачные технологии, юмор

Добрый день.

Предлагаю вашему вниманию перевод юмористического поста, посвященного облачным технологиям: It's The Future. Всяческие поправки и советы привествуются.

image

Эй! Привет! Мой босс сказал поговорить с тобой. Сказал, что ты много знаешь про веб приложения.

— Да, сейчас правда, я больше занимаюсь распределенными системами. Я только что вернулся с ContainerCamp и GlueCon, а еще я собираюсь на DockerCon на следующей неделе. Реально впечатлен тем, как двигается бизнес — все становится намного проще и доступнее! Это — будущее!

Здорово… Видишь ли, я сейчас разрабатываю простенькое веб-приложение — обычный CRUD на Rails, собираюсь деплоиться в Heroku. Скажи, Heroku все еще актуальна?

— Ты что! Нет. Это уже старая школа. Heroku — труп. Никто этим больше не пользуется. Теперь тебе нужно познать Docker. Это будущее!

Ах вот как. Ну ок. А что это?

— Docker — новый способ контейнеризации. Это как LXC, только еще включает формат запаковки контейнеров, а еще это распределительная платформа и ряд утилит, чтобы сделать построение распределенной системы реально простым делом.

Консерверезация?.. — что за? А что за LXE?

— LXC. Это как chroot на стероидах.

Что за cher-oot?

— Ясно… Смотри… Докер… Контейнеризация… Это будущее… Это как виртуализация, только быстрее и дешевле.

Окей, типа как Вагрант.

— Не, Вагрант — труп. Теперь все готовится к использованию внутри контейнеров, Это Будущее!

Ок, так мне теперь не надо ничего знать о виртуализации?

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

Так, что-то я смальца потерялся. Давай отматаем немного назад. Э… Так вот, есть виртуализация, называемая контейнерами. Я могу использовать это на Хероку?

— Что-ж, Хероку поддерживает Докер, но вспомни, что я говорил тебе. Хероку — труп. Тебе надо запускать контейнеры на CoreOS.

Что это?

— Это та самая крутая Host OS, которую ты сможешь использовать с Докером. Блин, да тебе даже Docker не понадобится! Ты просто можешь использовать rkt!

Rocket?

— Не, rkt.

Правильно, Rocket.

— Не, теперь это называется rkt. Полностью другая штука. Это альтернативный формат контейнеризации, который предоставляется как конкурент Докера.

Дак это выходит круто?

— Конечно, круто. Компонуемость — это будущее!

А ты этим rkt вообще пользуешься?

— Я не знаю. Я не думаю, что кто-то этим пользуется.

Эххх… Так ты что-то там про CoreOS говорил?

— Да… так вот, это Host, который ты используешь с Докером.

А что такое Host?

— CoreOS создана для оптимальной работы с контейнерами. Она настроена на работу с контейнерами.

Работу с контейнерами...?

— Да, у тебя же что-то там есть в твоих контейнерах. Так что, ты типа поднимаешь инстанс вроде Amazon EC2, поднимаешь там CoreOS host, дальше запускаешь демон Докера, и затем ты там уже можешь деплоить Докер образы.

Какая часть из всего этого — контейнер?

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

Ааа, типа Хероку?

— Нет… не Хероку. Я ж тебе говорил, что Хероку — труп. Ты запускаешь свое собственное облако используя Докер.

О_о?

— Да, это реально просто. Почитай про #gifee.

Gify?

— GIFEE — это Google Infrastructure For Everyone Else. Ты берешь все эти тулзы и стеки технологий, использующие контейнеры, и у тебя вся та инфраструктура, прямо как у самого Гугла.

Почему просто не использовать сервисы самого Гугла?

— А если через пол года там все полностью поменяется?

Хорошо, разве кто-то еще это все не хостит? Я реально не хочу сам хостить вот это все.

— Ну, AmazonECS, но тебе придется писать какую-то XML херь.

Что скажешь про OpenStack?

— Фу…

Послушай, я не хочу ничего хостить и обслуживать сам.

— Нет, это реально просто. Ты просто настраиваешь Kubernetes кластер.

Так мне нужен кластер?

— Kubernetes кластер. Он управляет деплоями всех твоих сервисов.

У меня только один сервис.

— О чем ты говоришь? Смотри, у тебя же веб-приложение, правильно?.. так значит у тебя должно быть 8-12 сервисов.

Что? Нет! У меня одно приложение. Сервис, похервис — пофигу! Всего одно долбаное приложение!

— Нет, смотри в сторону микросервисов. Это будущее. Это то, как мы все вокруг теперь работаем. Ты берешь свое супер-пупер приложение и разделяешь на 12 сервисов. По одному для каждой задачи.

Ну это уже чересчур…

— Это единственный путь убедиться, что конфигурация надежна. Так что, если твой сервис аутентификации грохнется…

Сервис аутентификации? Да е-мае, я просто собирался использовать тот же самый плагин, который использовал много раз до этого!

— Супер. Используй его. Положи его в отдельный проект. Накидай поверх его RestAPI слой. Потом твои другие сервисы будут использовать этот API и будут супер изящно обрабатывать отказы в работе. Положи его в контейнер и производи непрерывный деплой и интеграцию!

Будь по твоему. Теперь у меня на руках сотни неуправляемых сервисов и что дальше???

— Да, так вот я и говорил про Kubernetes… Он позволяет тебе удобно проводить оркестрацию всех твоих сервисов.

Проводить ОРКЕСТРАЦИЮ???

— Да! Вот, у тебя есть эти твои сервисы, и они должны быть отказоустойчивыми, поэтому тебе нужно запускать сразу несколько копий для каждого из твоих сервисов! И Kubernetes гарантирует тебе, что у тебя этих копий будет достаточно и они распределены между хостами в твоем fleet и всегда доступны.

То есть, мне нужен fleet?

— Да, для отказоустойчивости. Но Kubernetes сделает все за тебя. К тому же, ты уверен, что Kubernetes будет работать как надо, потому что его сделал Google, и еще потому что он работает на основе etcd.

Что такое etcd?

— Эта штука сделана на основе RAFT.

OK, что такое RAFT?

— Это как Paxos.

Господи, насколько глубокой будет эта сраная кроличья дыра, куда мы сейчас направляемся? Я просто хочу запустить одно сраное веб приложение!!! Твоюж мать!!! Окей, глубокий вдох, выдох… Ок, что такое Paxos?

— Paxos — это как тот самый старый распределенный протокол из 70х, который никто не понимает и не использует.

Отлично! Я так рад, что ты рассказал мне об этом! Так что такое Raft?

— Так как никто не понимает Paxos… эээ… кроме Диего…

О! Так ты его знаешь?

— Нет конечно, он работает в CoreOS. Так или иначе, Диего придумал Raft для своей кандидатской диссертации, т.к. Paxos был слишком сложен. Чертовски умный чел. И потом он написал etcd в качестве реализации и потом Афир сказал, что это действительно не говно, а круто!!!

Кто такой Афир?

— Афир — ну это тот чел, который написал, «Call Me Maybe», ну… ты же знаешь его? «the distributed systems and BDSM guy»?

Ты только что сказал BDSM?

— Да, BDSM. Это из Сан-Франциско. Все, кто относятся к распределенным системам. BDSM.

И он написал ту песню Кэти Перри?

— Нет, он написал серию блог постов о том что каждая база данных проваливает CAP.

Что за CAP?

— Тероема про CAP (известная также как теорема Брюера). Она говорит, что у тебя может быть только 2 пункта из трех: Консистентности, Доступности и Устойчивости к расщеплению.

И все базы данных заваливают эту CAP? Что блин это все значит?

— Это означает, что все это — отстой. Как Монго.

Я думал, что Монго горизонтально расширяемая.
Ладно. Так что там с etcd?

— Да, так вот, etcd — это распределенное хранилище значений.

Прямо как Redis.

— Нет, совсем не как Redis. etcd — распределенная система. Redis теряет часть информации если сеть временно отказывает.

Хорошо, это распределенное хранилище значений. Чем же эта штука так полезна?

— Кубернетес настраивает стандартный кластер из пяти узлов используя etcd как шину обмена сообщениями. Он комбинируется с парой своих собственных сервисов для предоставления весьма устойчивой оркестровой системы.

5 узлов? У меня одно приложение. Сколько машин мне нужно поднять для этого?

— Что ж, ты же собираешься поднять 12 сервисов, и конечно же тебе понадобиться пара лишних копий для каждого, пара балансировщиков, etcd кластер, твоя база данных и kubernetes кластер. Так что это может быть около 50ти одновременно работающих контейнеров.

ЧЗХ!

— Да ваще не вопрос! Контейреры реально эффективные, так что тебе не составит труда распределить все это дело между 8 машинами! Разве это не потрясающе?

И все-таки это только твое впечатление. И вот взяв вот это все, я смогу просто задеплоить мое приложение?

— Ну конечно. Правда, хранилище данных — все еще открытый вопрос в случае с Docker и Kubernetes, и сети придется прилично поработать, но эти вопросы очень скоро будут решены!

Хмм, понятно. Хорошо, я кажется теперь все понял.

— Супер!

Спасибо за развернутый рассказ.

— Да никаких проблем.

Позволь только мне подытожить все то, о чем мы говорили, чтобы убедиться, что мы друг друга поняли.

— Конечно!

Так вот, мне просто-напросто нужно разделить мое простое CRUD приложение на 12 микросервисов, каждое из которых должно быть обернуто в собственное АПИ, которые должны звать друг друга по этим АПИ но при этом обрабатывать ошибки каждого из них, положить все это в докер контейнеры, запустить fleet из 8 машин, которые являются Docker хостами на базе CoreOS, «оркестрить на них» используя небольшой Kubernetes кластер на базе etcd, разрешить «пару открытых вопросов» по поводу сетевой нагрузки и хранения информации и затем настроить непрерывный деплой и интеграцию нескольких копий каждого микросервиса за балансировщиками в мой fleet. Все так?

— ДА! Разве это не шикарно?

… Пойду деплоиться в Heroku.

Автор: PositiveAlex

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js