Это будущее

    Добрый день.

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


    image



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

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

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

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

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

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

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

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

    Что за cher-oot?

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

    Окей, типа как Vagrant.

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

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

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

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

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

    Что это?

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

    Rocket?

    — Не, rkt.

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

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

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

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

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

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

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

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

    А что такое host?

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

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

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

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

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

    Ааа, типа Heroku?

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

    О_о?

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

    Gify?

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

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

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

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

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

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

    — Фу…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Проводить оркестрацию?

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

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

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

    Что такое etcd?

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

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

    — Это как Paxos.

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

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

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

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

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

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

    Кто такой Aphyr?

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

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

    — Да, BDSM. Это Сан-Франциско. Здесь все увлечены распределенными системами и BDSM.

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

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

    Что за CAP?

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

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

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

    Я думал, что MongoDB горизонтально расширяемая.

    — Никто кроме тебя.

    Ладно. Так что там с etcd?

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

    Прямо как Redis.

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

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

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

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

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

    ЧЗХ!

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

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

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

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

    — Супер!

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

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

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

    — Конечно!

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

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

    … Пойду деплоиться в Heroku.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 37
    • +28
      Где мы свернули не туда?
      • +12
        В тот момент, когда люди вместо того что бы чинить старое, создают новое.
        • +3
          Не просто создают новое, а объявляют старое безнадежным и ожидают, что новое само собой будет лучше. Вместо старых проблем получают новые, плюс в новом коде непременно будут новые (свежие, если вам так приятнее) ошибки, какое-то время правят, потом «новое» опять объявляют безнадежным, процесс продолжается бесконечно.
        • +2
          Наверное когда ученик из этого коана стал учителем.
          Мастер Фу и десять тысяч строк
          Однажды Мастер Фу сказал заезжему программисту: «В одной строке кода shell-сценария больше духа UNIX, чем в десяти тысячах строк кода на С!»

          Программист, гордый своими познаниями в С, ответил: «Может ли быть такое? Ведь С — язык, в котором реализовано само ядро UNIX!»

          На это Мастер Фу ответил: «Это так. Тем не менее, в одной строке shell-сценария больше духа UNIX, чем в десяти тысячах строк С!»

          Программист выглядел удрученным. «Но ведь через язык С мы познаем просвещенность патриарха Ритчи! Мы уподобляемся человеку с операционной системой и компьютером, который получает непревзойденную производительность!»

          Мастер Фу сказал: «То, что ты говоришь, правда. Однако в одной строке shell-сценария больше духа UNIX, чем в десяти тысячах строк С».

          Программист усмехнулся и поднялся, чтобы удалиться. Но Мастер Фу кивнул своему ученику Ньюби, который писал строку shell-кода на стоящей рядом белой доске, и сказал: «Господин программист, посмотрите на этот конвейер! Не заняла бы его реализация на C десять тысяч строк?»

          Просматривая то, что писал Ньюби, программист что-то бормотал в бороду. В конце концов, он согласился, что это так.

          «И сколько часов потребовалось бы вам для реализации и отладки этой программы на языке С?»

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

          «Так кто лучше понимает дух UNIX?» — спросил Мастер Фу. «тот, кто пишет десять тысяч строк, или тот, кто, сознавая тщетность этих усилий, извлекает пользу, не программируя?»

          Услышав это, программист достиг просветления.

          При том что коан изначально очень мудрый. Но описанное в посте — это просто рекурсия этого коана. Учителя — ученики учеников этого ученика.
        • +6
          Это все Тьюринг виноват
          • +1
            Webscale же!
            • +19
              Подмена понятий. Можно написать аналогичный текст на тему «зачем мне IDE, гит, скрам, багтрекер, юнит-тесты, приемочные тесты, дженкинс, автоматический деплоймент, если я хочу написать hello world для лабораторки в универе».

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

              С распределенными отказоустойчивыми системами всё то же самое.
              • +24
                Насколько увидел я, тут высмеивается использование over9000 технологий как раз таки для «лабораторки в универе».
                • +9
                  Да, статья имеет несколько граней, в том числе, «не использовать модные новые технологии там, где они и правда не нужны, просто потому что это тренд». Т.е. как всегда, для каждого случая — определенный инструмент/подход.
                • 0
                  А напишите про IDE, раз можно, а то от vim отвыкнуть не могу (даже для небольших java коннекторов к разным API).

                  А пост классный, я для себя много почерпнул и увидел как все это связывается во едино.

                  • +2
                    А что про IDE? IDE — это качественный автокомплит, линтер, навигация по исходникам и документации. Если вы хорошо знаете все нужные вам API и используете скриптовый язык (или автоматическую рекомпиляцию), то IDE не так уж и нужно. Но лично я слишком быстро меняю библиотеки и технологии, чтобы заучивать их наизусть.

                    Насчет технических подробостей в этом посте — отнеситесь аккуратно, там есть неточности.
                    • 0
                      Вы немного лукавите. Если вы всерьёз используете vim, то у вас там к нему прилагается тонна собственноручно изготовленных или подобранных конфигов и скриптов, которые обеспечивают нормальную работу. Подсветку, автокомплит, рефакторинг, вот это вот всё.
                      Т.е. вы по сути написали собственную IDE, взяв vim в качестве основы. Ну, а кому-то не хочется тратить время на написание IDE, и он берёт уже готовую.
                      • 0
                        Вы плохо себе представляете работу в Vim.
                        Чем больше вы познаете его, тем больше плагинов вы начинаете удалять.
                        • 0
                          Вот кстати несогласен :)
                          • 0
                            Значит не достаточно познали еще? :D

                            Это не моя фраза, а из какой-то книжки, может быть practical vim, но за собой замечал такое, что все больше и больше плагинов убиваю.
                          • +1
                            Да, все так. Недавно поймал себя на этой мысли.
                            Однко же, удивительно встретить холивар vim/IDE в посте про докер.
                    • +8
                      It’s San Francisco. Everyone’s into distributed systems and BDSM.
                      Это из Сан-Франциско. Все, кто относятся к распределенным системам. BDSM.

                      facepalm.jpg

                      Перевод стоило бы вычитать перед публикацией. Две глобальные проблемы — повсеместная калька в порядке слов («Kubernetes кластер», «RestAPI слой») и то, что названия технологий то в оригинале, то транслитерированы на русский и склоняются. Нужно определиться.
                      • +1
                        Две глобальные проблемы — повсеместная калька в порядке слов («Kubernetes кластер», «RestAPI слой»)
                        Кубернетовый кластер и рестапишный слой, нет?
                        • +1
                          Прямой порядок слов подошел бы лучше, но и так тоже можно, если выдержать всю статью в едином стиле.
                          • +4
                            А вам не кажется, что «кластер Kubernetes» и «слой RestAPI» звучит как-то более… приятно для русскоязычного уха?

                            У меня есть своя теория заговора. Мне кажется, что Русский Язык пытаются захватить страшные люди с другой планеты, которые везде на вывесках пишут что-то типа «Эверест консалтинговая компания» и «33 Зуба стоматология».
                            • +3
                              А вам не кажется, что «кластер Kubernetes» и «слой RestAPI» звучит как-то более… приятно для русскоязычного уха?
                              Приятнее, но смысл не совсем совпадает. Лексически «кластер Kubernetes» ≈ кластер, составленный из Kubernetes'ов, тогда как Kubernetes-кластер («кубернетовый») — кластер, управляемый (или как оно там организовано?) Kubernetes'ом. Так же и «слой RestAPI» ≈ «слой всяких RestAPI», а «RestAPI-слой» — это слой, [отвечающий за / предоставляющий] RestAPI.
                              • +1
                                Во-первых, вы написали «Kubernetes-кластер» (через дефис), что уже значительно грамотнее. Во-вторых, никто не мешает написать «кластер типа Kubernetes» или «Kubernetes-управляемый кластер». Просто в оригинальном тексте было много игры слов, основанной на терминах и их альтернативном прочтении, поэтому, видимо, переводилось для «людей, которые знают английский, но которым лень читать по-английски всё».

                                Есть такая категория переводчиков, которые стремятся писать по-английски, но русскими словами и пунктуацией. Некоторые даже утверждают, что так «правильно» переводить художественные тексты. Правда как всегда где-то посередине. В любом случае, для того, чтобы ХОРОШО перевести текст, его придется спера ПОНЯТЬ. См. выше отличный пример про BDSM.
                          • 0
                            Спасибо, постарался исправить замечания.
                            • +2
                              Ну а что ж Вы корректный перевод не указали?
                              Это Сан-Франциско. Здесь все увлечены распределенными системами и BDSM.
                              • 0
                                Попробую еще точнее:

                                «Здесь все вовлечены в занятия или распределенными системами, или BDSM»

                                Так игра слов сохраняется. C «into».
                                • +4
                                  Какая тут игра слов? Вариант Source вполне точен, и звучит более естественно.
                            • +3
                              Это такой известный прием — заставьте своего оппонента выглядеть косноязычно. Например, попросив его без подготовки объяснить что-то очень сложное кому-то очень некомпетентному.
                              • +3
                                Монговато букв, но плюсанул)) «Усложнять — просто. Упрощать — сложно» (с).
                                • +4
                                  Из текста того же автора, но уже без сатиры:
                                  It’s really not unreasonable to look at the whole Docker and container thing and conclude that it’s all bullshit.
                                  Except it’s not.

                                  It’s actually the future of how we build applications.
                                  • 0
                                    Крутая статья, спасибо. Нужно было её переводить, а не вот что сверху.
                                  • +3
                                    Статье уже больше полугода, многое изменилось!
                                    • +7
                                      Добавилось больше слоёв? =)
                                      • 0
                                        Не только, Хероку тоже улучшается :)
                                    • +4
                                      Про сеть забыли!

                                      Что бы оркестрировать сеть — нужно построить оверлейную SDN сеть, например на OpenContrail, оно как раз прекрасно дружит с Kubernetes.
                                      • +5
                                        Это не Кэти Перри песня, а Карли Рей Джепсен же. Это важно.
                                        • +1
                                          Недавно на /sysadmin наткнулся на девопсовкий цитатник про это самое:
                                          “Re the LXD discussion above. I totally agree about containers being the best way to virtualize machines, and I can’t wait to start using it when Sun integrate it into Solaris ten years ago.”
                                          • 0
                                            Вы вот смеётесь, а мне сейчас один клиент мОзги клепает что чтобы переслать XMLку от одного приложения к другому, вероятно на одной и той же машине, нужно поднять SOAP Server (как он это называет). И если начать думать про все возможные alternative и exception flows, то становится уже как-то совсем не смешно.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.