Облачная эволюция
- Главная
- Блог
- Облака для бизнеса
- Облачная эволюция
Меня зовут Владимир Мельник, и я технический директор Tucha. Хочу поделиться некоторыми наблюдениями и выводами, которые я сделал в течение этого года, а также рассказать о перспективах дальнейшего развития индустрии облачных вычислений в Украине.
Речь пойдет о настоящей облако — среда распределенных вычислений и масштабируемых хранилищ, предназначенное для обеспечения работы приложений и хранения их данных. Это не совсем то же самое, что и виртуальные машины, которые по своему функционалу ничем не отличаются от физических серверов, а во многом и превосходят их, ведь они более надежные и одновременно простые в обслуживании. Этой полнофункциональностью мы, операторы, привыкли, скорее, гордиться, но всегда это именно то, что нужно для решения задачи заказчика?
Компания Tucha предоставляет сервисы облачных вычислений с 2012 года. Но, вспоминая этот факт, я должен сказать, что в том далеком году у нас только появились первые клиенты. А понимание того, что эта область имеет определенные перспективы на рынке Украины, пришло к нам еще раньше, в 2011 году. Это и стало причиной активной работы по созданию первых продуктов и их продвижение на рынок.
Достаточно четко помню, как 8 лет назад мы выходили на контакт с первыми потенциальными клиентами, которые никак не могли понять, о каких таких облака говорится и для чего они им нужны. Один из ИТ-менеджеров агрохолдинга даже не сразу понял, что речь вовсе не о облака, висящие над землей и поливают дождем бескрайние поля кукурузы. :-)
Это было очень давно, облачные вычисления еще не только «не стали мейнстримом»: очень мало людей в Украине вообще представляли себе, что это такое и для чего это нужно. ИТ-инфраструктура большинства предприятий, как правило, состояла из физических серверов, установленных в гермозоне ЦОД или серверных комнатах в офисах предприятия. Особенно быстро ребята такие серверы держали в арендованных квартирах, где время от времени возникали перебои с электропитанием или появлялся еще какой-то полтергейст в виде духа покойного прапрадеда, который выводит из строя пары в RAID-массивах. Однако облачные вычисления им тогда не были интересны: «Что это еще за облака? У нас, мол, и так все хорошо ».
И, знаете, сейчас тоже у всех все хорошо. Якобы.
А когда у всех все хорошо и спроса на какие-то новые сервисы, вроде, нет, операторам остается только хвастаться количеством сертификатов, петабайт емкостей и долями рынка. Новые сервисы не являются, поскольку поставщики услуг не видят на них спроса.
Сразу отмечу: я считаю, что виртуальные машины, особенно машины, работающие в надежной облаке, — это прекрасный инструмент. Наша компания для решения различных задач использует их уже более 10 лет, и вполне могу заявить, что я — фанат виртуальных машин. Говорить об их преимуществах в 2019 году, к счастью, уже не нужно, поэтому поговорим о некоторых ... если не недостатки, то, выражаясь корректно, особенности.
Представим, что мы собрались уехать, например, в командировку или отпуск. Пакуем чемоданы. В чемоданы можно положить очень много всего (в моей семье, например, есть настоящие профессионалы этого «тетриса»). Но, если мы каждый предмет будем складывать в отдельную коробку, в наши чемоданы поместится гораздо меньше предметов, не так ли?
Иногда использование виртуальных машин — это примерно то же самое, что и упаковки вещей в разные коробочки, поскольку каждая виртуальная машина является маленьким полноценным сервером (мы все же гордимся этой полноценностью, помните?). Поэтому у сервера есть выделенные ему процессоры, своя оперативная память, свое дисковое хранилище. Ресурсы выделяются с некоторым избытком, ведь, если нагрузка резко возрастет, ресурсы придется добавлять, а это часто сопровождается перезапуском виртуальной машины. И эти ресурсы, как правило, либо просто не используются (хотя место в чемодане они же занимают), или тратятся впустую (не забываем и о том, что каждая виртуальная машина несет в себе собственную операционную систему с кучей компонентов), даже несмотря на то, что эти системы в разных виртуальных машин одинаковы.
Конечно, оператор этому очень рад. Особенно, когда технологии виртуализации, используемых позволяют осуществлять дедупликации данных в хранилищах и в оперативной памяти.
И вот мы прибыли в пункт назначения. Так получилось, что один из чемоданов мы умудрились потерять. Возможно, нам удастся ее найти. Но это все равно означает, что даже в этом случае время то, что было в этом чемодане, будет нам недоступно. Что-то придется докупить, а без чего будем вынуждены и вовсе обойтись. И вот, оставшись в малознакомому городе без трусов, мы, откладывая менее важные, хотя и более интересные дела, спешим приобрести новые.
Я даже не говорю об авариях на стороне ЦОД, которые приводят к перебоям в работе тех или иных виртуальных машин. Виртуальный сервер, на котором работает единственный экземпляр того или иного сервиса, может сбоить и без влияния каких-либо факторов со стороны среды, в которой он работает. А количество способов самому выстрелить себе в ногу (хотя на виртуальном сервере, хотя физически) теоретически не имеет ограничений.
А вот если бы у нас вообще не было никаких чемоданов, а все, что нам нужно, — отель, который нас принимает, обеспечивает в полном соответствии с нашими спецификациями? Тогда мы везем с собой (или даже отправляем заранее) только четкие инструкции относительно того, какие трусы и какого цвета мы хотим находить в шкафу каждый день, каким должен быть наш чай, костюм нам понадобится в понедельник и какие шорты - во вторник. При этом мы хотим в любой момент изменять любые параметры: «Мне сегодня нужно в 3 раза больше кофе, чем обычно», «Завтра хочу надеть носки в горошек, а послезавтра — в полоску», «Утром хочу, чтобы в номере окна выходили на восток, а вечером — на запад ».
При этом можно составлять такие спецификации самому, можно загружать из сети что-то готовое и, если нужно, править их на свой вкус. И, что бы ни случилось, пока у нас есть наши спецификации, мы можем моментально воспроизвести то, что нам нужно, в необходимом количестве. Испачкали свой любимый костюм? Нет нужды нести его в химчистку: нам он не нужен, как, впрочем, и гостиницы, и отель его просто уничтожает и выдает нам новый.
Таким образом, нам не нужно возить с собой никакие чемоданы. У нас есть набор манифестов, которыми описывается вся архитектура. На основании этих манифестов система оркестрации создает нужные нам сущности тогда, когда они нам нужны, и удаляет их, когда необходимость в них отпадает.
Это и есть IaaC — infrastructure-as-a-code.
Это и есть настоящее облако.
Что еще характерно для такого облака? В настоящий облаке компоненты, обеспечивающие работу сервиса, одновременно работают на нескольких независимых друг от друга узлах.
Именно такая парадигма пока становится все более популярной: мы больше не запускаем монолитный приложение в одном экземпляре. Человеческая цивилизация наконец пришла к тому, чтобы разбивать приложение на множество микросервисов и запускать эти микросервисы в облаке в том количестве, которое необходимо, учитывая текущую нагрузку на каждый из них.
Онлайн-сервис не прекратит работу, если один из множества узлов внезапно выйдет из строя, ведь на всех узлах работают одинаковые реплики одного и того же контейнера, а система мгновенно исключает узел, упал, из списка получателей запросов.
То есть целая ферма вместо одной любимой коровы.
Те, кто уже в теме, хорошо знают, чем еще характерно это облако.
Возможность запускать необходимое количество экземпляров одного и того же микросервису — это возможность легко переживать резкие скачки нагрузки без необходимости срочно добавлять процессорные ядра и оперативную память на сервере (а чаще всего — с перезагрузкой системы).
Я уже не говорю о мониторинге метрик, анализ журналов регистрации событий, автоматическое горизонтальное масштабирование и другие чудеса техники.
И как тут не вспомнить о тех компаниях, которые сами разрабатывают те или иные программные продукты и предоставляют онлайн-сервисы, доступные миллионам пользователей.
Еще в прошлом году мы столкнулись с тем, что все они в разной степени заинтересованы в автоматизации процессов CI / CD. Если усреднить, наши заказчики пожелали видеть это в виде такой цепочки:
- программист делает очередной Коммит;
- платформа разработки делает анализ изменений;
- происходит компиляция кода с учетом этих изменений,
- запускаются юнит-тесты, проверяют, ничего не сломалось;
- новая версия приложения попадает сначала на стейдж, где ее тестируют QA-инженеры;
- новая версия приложения осторожно попадает в продакшн, при этом система сначала запускает новые контейнеры, убеждается в том, что они чувствуют себя хорошо, и только после этого переключает трафик на них.
А самое важное в этом вот что: все это происходило автоматически. То есть вполне без участия людей, которым и так есть, чем заняться.
Обычно именно для обеспечения всех этих процессов компания, предоставляющая собственные онлайн-сервисы, и снимает специалистов в области DevOps или отдает эти задачи на аутсорс. А есть и такие, кто уже привык всегда обращаться к специалистам из службы поддержки своего оператора облачных вычислений.
А нас, я честно в этом признаться, очень легко спровоцировать, подбросив нам задачу, решение которой не является для нас чем-то тривиальным. Мы — компания, которая уже более 13 лет предоставляет услуги, связанные с хостингом веб-приложений, и первыми в Украине запустили IaaS. И до сих пор очень боимся показаться недостаточно сообразительными, клиентоориентированными и динамичными, чтобы освоить что-то новое. И пришлось разбираться, как же автоматизировать CI/CD. Конечно, очень быстро пришли к использованию Docker-контейнеров. Сначала пытались автоматизировать работу с ними какими-то своими костылями, но вовремя открыли для себя Kubernetes, а вместе с ним — и всю огромную kloud-экосистему.
Поэтому вот, хорошенько разобравшись, мы решили систематизировать накопленный опыт и извлечь из него дополнительную пользу. Так и появилась новая платформа — TuchaKube.
Это не только хостинг контейнеров в Kubernetes-кластерах. Это среда, в которой уже настроено мониторинг, масштабирование, выпуск сертификатов, персистентность данных, кластеры СУБД и другие службы. Это сервис автоматизации CI/CD. Это частные репозитории для кода, для артефактов, для контейнеров. Это то, чего в Украине еще не было.
Как говорится, лучше один раз увидеть. Поэтому предлагаем вам посмотреть некоторые видеодемонстрации основных функций платформы TuchaKube:
Мы планируем выпуск еще нескольких серий, посвященных обеспечению персистентности данных, защиты веб-приложений от атак злоумышленников и другим не менее интересным темам. Чтобы не пропустить новости, советуем подписаться на наш YouTube-канал и страницу Facebook.
И, конечно же, призываю всех обращаться к нам с задачами, в решении которых сервис TuchaKube может быть полезным. Рады вам 24/7!
