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

— Еще до начала полномасштабной войны у нас в Украине была стратегия Cloud First. Она была направлена ​​на то, что все владельцы данных будут постепенно переходить в облако. Следовательно, компании и государственные структуры приступили к такому переходу. Появилось больше локальных провайдеров, которые могли предложить облако.

Но после начала широкомасштабки бизнесы, банки, государственные структуры перенесли большую часть данных за границу — в облака гиперскейлеров, таких как AWS или Microsoft Azure, при условии огромных скидок или вообще бесплатно. Сейчас, в 2024 году, эти льготные условия постепенно начинают исчезать. И владельцы данных решают: возвращаться ли в Украину или оставаться где-то в Европе. Интересно узнать, как вы наблюдаете этот процесс переездов украинских клиентов со своей стороны?

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

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

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

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

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

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

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

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

— Но клиенты понимают, что их не может поддерживать только один провайдер, учитывая все риски. И потому они могут частично переехать, например, куда-нибудь в Европу.

Видите ли вы дальнейший процесс этого движения в Европу из Украины? Или он остановился?

Нет, точно не прекратилось. Украинцы сейчас внимательнее думают о том, где расположены дата-центры. И, честно говоря, мы видим, что некоторые украинские компании обеспокоены тем, что некоторые дата-центры расположены вблизи российской границы. И это ясно. Хотя вероятность того, что там что-нибудь произойдет, достаточно мала.

Поэтому мы, например, сейчас рассматриваем и активно расширяемся также в Западной Европе, чтобы помочь тем клиентам, которые хотят, чтобы их данные были перенесены дальше от российской границы. Мы идем в такие страны, как Германия, Дания и так далее. Буквально в прошлом месяце развернули собственную инфраструктуру во Франкфурте-на-Майне.

— Если данные будут размещены данные от Украины, то что происходит задержкой сигнала из-за расстояния между серверами? Не проблема ли это для бизнеса, с технической точки зрения?

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

Во-первых, это потому, что покрывающая Европу оптическая сеть настолько развита, что, например, от Киева до Риги сигнал идет примерно 30 миллисекунд. И, честно говоря, очень трудно найти программы, на которые может оказать существенное влияние такая задержка.

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

— Давайте поговорим об эволюции в области хранения данных. Я слышал реальные истории, что как только начались отключения электроэнергии, некоторые украинские компании просто привозили серверы из южной или восточной части Украины в Киев, в центр обработки данных, и сказали, что «все наши данные находятся на этих серверах». Но снова запустить систему было тяжело, потому что все данные были даже не на виртуальных машинах, а на серверах, не приспособленных к работе в профессиональных дата-центрах.

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

20–30 лет тому назад все жило на физических серверах. Так что у вас был физический сервер, вы устанавливали операционную систему поверх него. И если вы хотели, чтобы все работало безопасно, вы устанавливали только одну программу на него. Но в большинстве случаев вы установили кучу программ. Затем, когда вам нужно пофискить сервер, все вышло из строя и все программы исчезли.

Эту историю тяжело было масштабировать. Большинство этих серверов использовались неэффективно.

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

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

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

Так появилось гораздо лучшее использование ресурсов. Да, это безопаснее, эффективнее, но все равно всегда есть куда развиваться. Всегда бывают случаи, когда виртуальные серверы не так гибки, как хотелось бы.

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

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

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

Контейнер чрезвычайно мал, чрезвычайно быстр, вы можете открыть контейнеры, можете умножить их, и вы можете масштабировать их в считанные секунды.

— И чтобы управлять этими контейнерами, вам нужна специальная система, и она называется Kubernetes, не правда ли?

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

— Я слышал об этом, на греческом языке Kubernetes — это Stearman.

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

Так вот, я недавно начал смотреть Star Trek. Это научно-фантастический сериал 80-х.

Borg во вселенной Star Trek — это такая разновидность инопланетян, тесно сотрудничающих друг с другом. Они всегда взаимосвязаны. Нет ничего индивидуального. Они все вместе работают как один огромный организм.

И Google также назвал эту инфраструктуру Borg, потому что идея с управлением контейнеров очень похожа.

Это как одна большая структура, и если один контейнер упадет, это не суть важно. Система сразу вызывает еще одну.

— Если мы говорим о Kubernetes и мы говорим о задачах, которые он может помочь решить, как вы можете нарисовать его типичного клиента? Кто в Украине может быть заказчиком такого решения, как CaaS (Container-as-a-service), например?

Что ж, если мы говорим о CaaS или KaaS, то есть о контейнерах как услуге, или Kubernetes как услуге, в любом случае мы создаем сервисы на базе существующей инфраструктуры, потому что создать собственную среду Kubernetes нелегко.

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

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

Итак, вместо того, чтобы долго строить все по частям, когда вы берете каждый маленький блок и затем пытаетесь сопоставить его с другими, чтобы построить ваш идеальный контейнерный кластер, вы можете просто получить это как услугу и запустить свой кластер Kubernetes, например, в Tet Cloud, или в Azure, или где угодно.

И это существенно упрощает задачу.

— А что касается профиля компании?

Это может быть любая компания, разрабатывающая что-то новое. Поскольку в таком случае вы вряд ли увидите, что кто-то перемещает в облако какие-то устаревшие программы, что-то вроде CRM, которым пользуются в течение десяти лет. Вряд ли это соберутся когда-нибудь превратить в контейнеры. Я не думаю, что вы получите от этого большую пользу, это будет стоить многое, и нет смысла это делать.

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

Это действительно помогает как в масштабируемости программы, так и в гибкости инфраструктуры. Решение тоже очень помогает в разработке, потому что Kubernetes легко интегрируется в процессы CI/CD. Здесь удивительная особенность: программист, который пишет код, может очень легко публиковать его, может вносить изменения в код и автоматически предоставлять его для тестирования или использования. И ему больше не нужно ждать, пока специалисты по инфраструктуре запустят новые виртуальные серверы. Все подтягивается и происходит автоматически.

— Так это может быть стартап или, может быть, даже крупная корпорация, запускающая свои новые серверы?

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

Стартапы вообще строят только с нуля, и это преимущественно молодые ИТ-шники, открытые к новым идеям, им очень удобно строить свои проекты с помощью контейнеров.

— Дешевле ли использовать контейнеры как услугу для запуска проектов?

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

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

— Каковы ваши рекомендации компаниям, стартапам, которые выбирают облачное решение и Kubernetes в качестве услуги? На какие моменты им нужно обратить внимание?

Мы всегда стараемся привлечь внимание, например, нового стартапа, когда они запускают свою программу, к тому, что они сначала должны решить, где именно они будут ее создавать. Очень часто мы видим, что стартапы просто видят свой выбор между тремя гиперскейлерами, то есть Microsoft, Amazon или Google. И они полностью игнорируют все другие варианты на рынке, что, по моему мнению, упущенная возможность.

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

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

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

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

— А какая ваша сильная сторона?

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

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

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

Читайте главные IT-новости страны в нашем Telegram

По теме

Читайте главные IT-новости страны в нашем Telegram

Підключай Megogo зі знижками за акційними тарифами.

від 99 гривень на місяць