Джо Бе́да, один из создателей Kubernetes : «Разработка ПО — командный спорт»
Вступление
Недавно мы побеседовали с главным инженером VMware Джо Бе́дой, одним из создателей Kubernetes и Google Compute Engine. Джо — инженер-программист с большим опытом: он работал в Microsoft и в Google, а также был соучредителем лидера облачных технологий — компании Heptio, которая в настоящее время входит в состав VMware. Надеемся, вам будет интересно.
Интервью
Evrone: Привет! Рады тебя видеть. Итак, первый вопрос. В настоящее время приложения помогают абстрагироваться от физического оборудования путем виртуализации. Использование контейнеров позволяет не зависеть от ОС и сэкономить массу системных ресурсов. Такие платформы, как Kubernetes, освобождают от необходимости ручного управления, нам не приходится заботиться о том, как и где работает приложение. Не означает ли это, что мы теряем контроль, а устранение неполадок у клиентов усложняется
Джо: Привет, спасибо за приглашение! Я не считаю, что обязательно абстрагироваться от операционной системы. Ведь когда запускаешь что-то внутри контейнера, всё равно знаешь, что работаешь в Linux. Есть пара вещей, которые очень помогают нам в попытках создать этакий волшебный эффект: «Возьмите мой код и запустите его. Мне всё равно, где он будет запущен, главное, чтобы работал». Первое — эффективность контейнеров, часто в сочетании с виртуализацией. Не меняя оборудования, вы сможете упаковать больше, вы можете более тонко управлять выделением ресурсов и выбирать компромиссы.
Но еще важнее то, что благодаря контейнерам мы получаем гораздо более упакованную, изолированную единицу развертывания. Таким образом, у нас наконец-то есть возможность запустить серверную часть приложения на чём угодно: на ноутбуке, в одном облаке или в другом облаке. И почти всегда программа будет работать. Один и тот же артефакт может работать в различных средах, практически без изменений. Такая единица развертывания — это невероятно мощный строительный блок, с которым мы можем работать.
Запуск процессов — это здорово, но обычно бесполезно, если у вас нет сетевого доступа в хранилище. Вот где возникают настоящие сложности. Взять контейнер, решить задачу об упаковке в контейнеры так, чтобы они работали на множестве хостов — это одно, но другое дело превратить всё это в нечто полезное: наладить сетевое взаимодействие, чтобы эти вещи общались друг с другом, чтобы нужное хранилище было в нужном месте и в нужное время — все эти факторы сильно осложняют проблему.
Evrone: Ты сказал: мы знаем, что контейнер работает на каком-либо ядре Linux, но Microsoft сейчас интенсивно развивает подсистему Windows для Linux. Как ты считаешь, может быть с этого начнётся эра интеграции контейнеров в Windows?
Джо: У меня нет особого опыта работы с подсистемой Windows для Linux. Этим занимаются некоторые мои бывшие коллеги по Microsoft. Кстати, вот показатель, насколько мала наша отрасль — мы постоянно, так или иначе, пересекаемся со знакомыми по прежней работе людьми. Как я понимаю, вторая версия подсистемы Windows для Linux на деле — это ядро Linux, запущенное на виртуальной машине с некими тонкими взаимодействиями между ним и остальными файловыми системами и сетью Windows.
Когда я пробовал подсистему, меня впечатлила действительно интересная технология. С её помощью можно запустить контейнерный движок, к примеру, Docker, прямо на месте и может показаться, что Linux находится на вашем рабочем столе, потому что это так и есть. У вас есть ядро. Это просто пользовательский интерфейс к нему, немного странный по сравнению с более традиционной системой Linux. Я думаю, важно понимать, что это совершенно другой механизм, чем нативные контейнеры Windows. Контейнеры Windows сложны, потому что Windows не была создана для того, чтобы ею можно было управлять так, как ожидают контейнеры. Существуют глобальные реестры, глобальные ресурсы, и создать способ, чтобы изолировать все эти вещи, довольно сложно.
Я так понимаю, что с точки зрения зрелости и, контейнеры Windows всё ещё находятся на ранней стадии развития. Теперь, когда программисты Windows идут в этом направлении, очевидно, что если использовать C++ или языки более низкого уровня, то заметны большие различия, когда вы ориентируетесь на Windows с Win32 или на Linux. В плане модели — это довольно глубокие различия.
Но при использовании языков более высокого уровня различия не столь велики. С учетом того, что Microsoft движется в направлении платформы .NET Core, на которую действительно можно перевести все эти вещи, мы видим, как начинается отделение модели программирования для высокоуровневых сред от базовой операционной системы. При этом всё ещё существует довольно много стандартов .NET. По-прежнему есть довольно много зависимостей от нативных Windows DLL, особенно при кодировании мультимедиа, например. И есть ещё много мест, где людям приходится использовать рабочие нагрузки Windows. Вот почему я считаю, что работа над контейнерами для Windows продолжается. Но многое, например, .NET Core с поддержкой Linux, — было не так критично, как может казаться.
Evrone: Ты упомянул о своей карьере в Microsoft и работе над браузером Internet Explorer. Какой самый полезный опыт ты тогда приобрел?
Джо: В процессе карьерного роста мы учимся в самых разных аспектах. Строго говоря, с технической точки зрения, систему профилирования памяти внедрил до меня более опытный инженер. В ней проверялся практически каждый случай выделения памяти в Internet Explorer и в основном механизме рендеринга, а мы ставили тег, создавали иерархию и могли в реальном времени видеть, куда расходуется память. Это был режим отладки, который мы могли по-настоящему использовать. И это был один из тех случаев, когда система становится настолько сложной, что непонятно, что происходит, причем, если получается пролить свет на происходящее, ты обязательно удивишься. Я сталкивался с этим вновь и вновь на протяжении своей карьеры. У тебя есть теоретические представления, ты начинаешь проверять эти теории на практике — что же на самом деле происходит с твоим кодом в программе? И всегда оказывается, что ты ошибался.
Посмотреть, вот что действительно нужно. Я имею в виду, что теории — это здорово, но обязательно требуется проверить их на практике. И не надо браться оптимизировать что-то, пока не убедишься, что собираешься оптимизировать реальную проблему, реальное узкое место.
Что касается профессионального развития... Это было в самом начале, вероятно, во время разработки Internet Explorer 5 или Internet Explorer 6. Я начинал понемногу брать на себя роль лидера. И не забудь, что Internet Explorer в то время был нацелен на Win9x, в дополнение к NT. Довольно мало памяти, маломощные машины... Первоначальные версии IE4 работали на 48 или 64-мегабайтных машинах. Это был совсем другой мир, нежели тот, в котором мы сейчас живем.
Но я действительно помогал повышать производительность движка Internet Explorer и движка рендеринга. Мы одержали чрезвычайно важную победу над Netscape, нашим основным тогдашним конкурентом. Горизонтальное распределение ролей меня многому научило. Высокая производительность достигалась не благодаря ролям и отношениям начальник/подчинённый, а стихийно. Это была настоящая школа для меня. Как руководить неформально, опираясь на личное влияние? Как заставить людей делать что-то, когда у тебя нет права напрямую управлять тем, что они делают? И знаешь, в самом начале я наделал ошибок. Я пытался направлять процесс, просто указывая: «Мы должны сделать то-то и то-то», полагаясь на свой авторитет (которого у меня, возможно, не было). Это не очень-то работало.
Я задумался: как на самом деле понять, что стимулирует людей? Каковы их цели? Как на самом деле создавать беспроигрышные ситуации, в которых люди будут сотрудничать с тобой, даже если у тебя нет полномочий указывать им, что делать? Это навык, который приходится развивать на протяжении всей своей карьеры. Пожалуй, это показывает, что разработка программ — это командный спорт, если не сказать больше. Тут действительно нужно, чтобы люди работали вместе, заодно. И это не менее важно, чем выбор основной технологии или создание большого количества отличного кода.
Evrone: Да, старые добрые времена. Ты тогда предпочитал Internet Explorer или Netscape Navigator?
Джо: Можно многое рассказать о том, что происходило тогда. Когда я перешёл из Microsoft в Google, одной из самых больших перемен была идея, которой руководствовался тогда Google «давайте сделаем, как лучше для клиентов» вместо «давайте уничтожим конкурентов». И я думаю, что эта сосредоточенность на пользователях, а не на конкуренции, осталась со мной до сих пор. Я не в курсе, поступают ли так в Google и сейчас.
Я перенял эту идею: нужно просто делать правильные вещи для пользователей. Но в начале моей карьеры Microsoft во многом придерживался принципа «уничтожим конкурентов». Оглядываясь назад, я думаю, что это было нездоровое отношение с точки зрения того, как IE позиционировался на рынке. Но что касается технологии, IE4 был тогда намного лучше, чем Navigator. Приведу пример. У нас была, по сути, модель страницы in-memory, на основе которой можно было программировать. Модель структуры документа DOM, которую используют современные браузеры, на самом деле началась с IE4. Именно команда этого проекта продвигала идею, что модель программирования и разметка должны быть согласованы, и всё, что вы могли бы сделать в разметке, вы можете доработать позже во время выполнения с помощью JavaScript. Navigator в то время не имел такого рода модели.
Что происходило, если изменяли размер окна Navigator’а? Браузер повторно парсил исходный текст страницы, чтобы перерисовать её, потому что не имел модели страницы в памяти, чтобы рисовать на её основе. Иногда при изменении размера окна приходилось даже перезагружать некоторые материалы. Динамика тогдашнего Navigator сводилась к тому, что имелось несколько веб-страниц, нарисованных одна поверх другой, и можно было заменять некоторые из них. Это были слои Netscape.
Я считаю, что именно IE4 заложил основу для современных браузеров. Было внесено много улучшений; было сделано много отличных вещей. Стандарты в то время как раз развивались. Часто IE опережал стандарты, а затем стандарты менялись вслед за ним. Кроме того, всегда сложно искать компромисс между совместимостью и стандартами. Вряд ли существуют инструменты или методы, которые всегда помогут ориентироваться в таких ситуациях. В то время мне действительно нравился IE, потому что мы делали что-то действительно интересное с точки зрения создания современного веб-браузера. Мы называли это HTML Dynamic, DHTML, но, по сути, результат нашей тогдашней работы — современная DOM.
Evrone: Да, мы это прекрасно помним. В одном из своих выступлений ты сказал, что Kubernetes — это платформа платформ. Какая платформа на базе Kubernetes самая успешная, как ты считаешь?
Джо: Если честно, я думаю, что мы всё ещё учимся, и одна из причин успеха Kubernetes заключается в том, что нам не обязательно иметь единую монолитную платформу, построенную поверх Kubernetes. Поясню это на противоположном примере. Если взять модель расширяемости чего-то вроде Mesos, то Mesos был, по сути, ядром инструментария, а затем на его основе можно было строить такие вещи, как Marathon, Aurora или Chronos, которые были системами, использующими ядро планировщика для выполнения задач. Но Aurora, Marathon и Chronos имели свои собственные API. У них была своя пользовательская система. У них был свой собственный способ моделирования мира. В итоге они оказались изолированы.
Для Kubernetes мы создали общий API для общего набора моделей, все эти вещи вокруг CRUD. Мы обнаружили, что люди, которые создают расширения Kubernetes, часто налаживают взаимодействие с другими её расширениями. То есть то, что создано на основе Kubernetes, работает не в замкнутом пространстве, а действительно обогащается за счет остальной экосистемы. Мне кажется, что в этом большое отличие Kubernetes. Вы обнаруживаете, что у нас есть общие компоненты, которые актуально развиваются. Иногда есть единственные в своём роде проекты, например, cert-manager. Это расширение Kubernetes, которое используют все.
Мало тех, кого оно не устраивает, и кто создаёт собственные системы управления сертификатами в этом ключе. Возьмём другой пример — есть процветающая экосистема ingress-систем для Kubernetes, позволяющая выбирать и применять их, будь это Nginx Ingress или HAProxy Ingress, или продукты на базе Envoy, или решение, разработанное для конкретного облака. И все эти вещи могут до определенной степени работать вместе. Я думаю, что вместо платформы на основе Kubernetes мы имеем кучу строительных блоков, которые можно соединить, чтобы создать ту платформу, которая действительно отвечает вашим потребностям.
При этом тут есть пространство для манёвра, и это часть работы, которую мы проводим в VMware с Tanzu. Мы хотим свести бесконечное число существующих вариантов выбора (что часто действует угнетающе на начинающих пользователей) к следующему предложению: «Эй, если вы начнете с этих вещей, собранных вместе таким вот образом, у вас всё получится». А когда вы лучше поймете свои потребности, глубже разберётесь с системой и экосистемой, тогда вы сможете использовать другие вещи и настраивать их под свои уникальные потребности. Единой платформы не существует, но есть возможность собрать все части воедино, чтобы облегчить начало работы как для отдельных людей, так и для организаций.
Evrone: Большинство экспертов, описывающих Kubernetes, отмечают высокий порог входа. Хорошо ли это для платформы или нет? Не стоит ли его понизить и упростить для новых пользователей?
Джо: Это действительно сложная тема. Высказывание, которое здесь к месту: «Есть ненужные сложности и имманентные сложности». Зачастую, если вы пытаетесь чрезмерно упростить систему, она становится нестабильной, а набор ситуаций, в которых она может работать, относительно узким. Мы видели это на примере многих ранних предложений типа Platform-as-a-Service. Сначала показалось, что это здорово. Вы могли многое сделать, но потом, в конце концов, упирались в какую-то стену. И вариантов было не так много. Приходилось забирать часть своего приложения, часть своей программы и начинать всё сначала, в какой-то степени в другой среде. Я думаю, это потому, что решения были слишком упрощенными.
Другой подводный камень чрезмерного упрощения заключается в том, что вы можете сделать что-то, что кажется простым на первый взгляд, но под этим скрывается море сложностей. Зачастую, если в вещах появляется слишком много «магии», становится гораздо сложнее понять, что происходит на самом деле. Я думаю, что развертывание горизонтально масштабируемых распределенных приложений на пуле машин, использующих всевозможные внешние службы, такие, как балансировщик нагрузки и динамическое хранилище, — это трудная в своей основе задача, и в ней много сложностей. И даже с тем уровнем гибкости, который дает Kubernetes, трудно, на мой взгляд, упростить её ещё больше. Да, в Kubernetes определенно встречаются места, где есть ненужная сложность, но думаю, что это неизбежно в любой реальной системе.
Однако я также считаю, что это сложная проблема, а сложные проблемы требуют относительно сложных решений. Мы как-то забываем об этом. Представьте себе человека, который только начинает осваивать компьютеры — как он знакомится с программированием и работой вещей типа Linux? . Ему приходится преодолевать огромное количество сложностей, чтобы достичь уровня, на котором он действительно сможет работать с такими вещами. Аналогично, взгляните на любое крупное облако, например AWS. Оно ни в коем случае не является простым. Там много сложностей, но вы видите, что это набор инструментов, который можно использовать по-разному, так что эта сложность кажется оправданной.
Я думаю, что некоторые из этих рассуждений применимы и к Kubernetes. Сложность оправдана. Проблема в том, что Kubernetes всё ещё новая платформа. По мере того, как решение обретает зрелость, обретает целостную форму, когда в отрасли формируется общее понимание идеи, сложность имеет тенденцию отступать на задний план, её перестают замечать. Но новым пользователям всё равно приходится с ней сталкиваться. И мы видим это, когда в нашу отрасль приходят новые разработчики. Им нужно многое понять. Давай уберём Kubernetes из уравнения. Нельзя сказать, что в нашей индустрии всё легко и просто. Но мы точно знаем, что освоив что-то, мы вдруг забываем о трудностях освоения. Мы забываем об этой боли. И я думаю, что с Kubernetes наблюдается похожая динамика.
Evrone: Две недели назад наша команда присутствовала на одном из крупнейших технических мероприятий. И одной из горячих тем конференции была следующая: стоит ли разработчикам уделять внимание изучению основ Kubernetes или лучше оставить это системным администраторам или специалистам DevOps и сосредоточиться на написании хорошего кода?
Джо: Смотря что подразумевать под «разработчиками». Мы часто упоминаем разработчиков, как единую группу, но на самом деле существует множество различных типов разработчиков, и у них разные проблемы, им нужны разные знания. Возьмём, к примеру, игровые движки. У меня есть школьный друг — он делает ААА-игры с микрооптимизациями. Для меня это абсолютно другой мир. Вопрос: если вы разрабатываете игру, стоит ли вам просто использовать что-то вроде Unreal Engine и не беспокоиться о технологиях рендеринга, которые действуют где-то там внутри? Или стоит всё же обратить внимание на то, что происходит с графическим процессором? Ответ зависит от того, к какому типу разработчиков вы относитесь.
Я думаю, появятся разработчики, которые будут глубже вникать в имеющиеся системы развертывания, которым придётся знать Kubernetes, и именно они будут разрабатывать платформы. Зачастую именно эти люди сейчас тяготеют к смешанным ролям DevOps, где они находятся на самой границе событий между приложением и средой, в которой работает приложение. И по-прежнему будут разработчики, которые никогда не пишут бизнес-логику и не интересуются этими вопросами.
Так что оба подхода имеют право на жизнь. Я думаю, что одна из причин споров вокруг термина "cloud-native", или вокруг "DevOps" и "cloud-native", которым очень трудно дать определение — это то, что нет авторитета, который может сказать нам, что на самом деле означает "cloud-native". На мой взгляд, cloud-native — это, по сути, возможность использовать лучшие преимущества подобных облаку платформ, где подобная облаку платформа — это нечто, управляемое API, самообслуживающееся и эластичное, а Kubernetes является такой платформой. Преимущество, которое мы получаем, используя cloud-native, заключается в следующем: есть ряд людей, которые создают и раскрывают возможности платформы, и есть ряд людей, которые что-то строят на этих платформах, при этом и те и другие являются разработчиками.
В обоих случаях есть роль эксплуатационников и разработчиков. Те, кто курирует, разрабатывает и специализируется на платформах, должны знать Kubernetes достаточно хорошо. Для тех, кто занимается строительством на её основе, всё зависит от того, что они делают. Если они делают простые трехуровневые веб-приложения, им не обязательно хорошо знать Kubernetes, потому что эти паттерны довольно известны.
Но если вы делаете что-то вроде супервысокодинамичной распределенной системы с машинным обучением, вам, вероятно, придется углубиться в среду, на которой вы работаете, потому что это более специализированная архитектура, и вам придется копать немного глубже. Опять же, если вы делаете простую игру, вам не нужно вдаваться в низкоуровневые детали. Но если делать более продвинутые игры, то приходится фактически создавать расширения на C++ для своего игрового движка. «Разработчики» — это не монолитное понятие, всё зависит от ситуации.
Evrone: Есть злая шутка, что cloud-native — это то, что нельзя запустить или отладить на ноутбуке.
Джо: Ха-ха, ну, до определенного уровня можно доверять провайдеру. Есть точка, в которой вы не можете отладить то, что происходит, и наличие такой точки одновременно развязывает руки, потому с неё начинаются проблемы кого-то другого, и это здорово. Но для разработчиков того типа, которые любят углубляться в тему и пытаются понять, что происходит с пакетом вплоть до аппаратного уровня, облако создает своего рода барьер, через который нельзя выполнять отладку, и это иногда смущает людей, привыкших очень глубоко вникать во всё, что они делают.
Evrone: В настоящее время мы наблюдаем тенденцию перехода к микросервисной архитектуре. По твоему профессиональному мнению, является ли контейнерная оркестровка единственным способом эволюции микросервисов?
Джо: Нет, конечно. Часто делают микросервисы без контейнеров. Многое из гранулированной, сервис-ориентированной работы и инфраструктуры-как-кода было с самого начала сделано компанией Netflix, и она гордится этим. Ты знаешь, что многое из этого было сделано на EC2 с использованием AMI и тому подобного. Такие техники могут работать и без контейнеров. С другой стороны, можно использовать контейнеры без микросервисов, но контейнеры и микросервисы замечательно работают вместе. В таких случаях нет единственного правильного ответа. Есть только набор инструментов, техник и шаблонов, которые можно использовать для решения задач. И микросервисы, и контейнеры тоже всего лишь пара инструментов и шаблонов, которые хорошо работают вместе.
Evrone: Мы часто говорим о преимуществах систем оркестровки контейнеров, особенно на конференциях, но есть ли какие-то недостатки, что-то, что тебе не нравится или что ты хотел бы изменить?
Джо: Пожалуй, там просто всего слишком много. При решении простых проблем Kubernetes, вероятно, не нужен, и контейнеры, возможно, тоже. Бывают ситуации, когда вы делаете что-то действительно простое, запускаете виртуальную машину, устанавливаете Docker, запускаете единственный контейнер, и вот вы вне конкуренции. Во многих случаях это работает очень хорошо. Kubernetes и контейнеры не решат все проблемы для всех. Исходя из этого я считаю, чем больше вы сможете переложить управление кластером Kubernetes на кого-то другого, тем полезнее и проще он станет.
Что бы я хотел изменить? Пока не знаю. Наверное, ещё слишком рано делать окончательные выводы. Определенно есть вещи, которые мы стараемся улучшить. Управление жизненным циклом, своего рода администраторский аспект Kubernetes, как вы на самом деле управляете кластером? Это оказалось намного сложнее, чем мы предполагали на ранних этапах проекта. Мы много работаем над тем, чтобы использовать шаблоны контроллеров Kubernetes для управления кластерами Kubernetes. Это Cluster API и тому подобное.
Я думаю, что способ, которым мы управляем (и усмиряем) YAML и устанавливаем программное обеспечение, все ещё очень раздроблен и сложнее, чем должен быть. Удивительно, что при немалом пути, который прошёл Kubernetes, у нас всё ещё есть люди, имеющие дело с YAML напрямую. Я выступил с докладом под названием I'm Sorry About the YAML ("Извините за YAML"), где подробно остановился на некоторых деталях этого вопроса. Я думаю, что все эти проблемы решаемы. Необходимости в каких-то фундаментальных изменениях я не вижу. Я думаю, что со временем мы сможем всё исправить, для этого нужно прислушиваться к отзывам, работать и постепенно вносить улучшения.
Evrone: И наш традиционный вопрос о балансе между работой и личной жизнью. Твою жизнь, должно быть, заполняют колоссальные, высоконагруженные проекты. Что ты посоветуешь коллегам-разработчикам, чтобы сохранить эффективность при большом количестве задач и сделать мир лучше для себя и всех остальных?
Джо: Существуют разные способы быть эффективнее и результативнее. Выбор зависит от того, каким разработчиком вы хотите быть, и каковы ваши навыки и пристрастия. Я не верю в разработчиков, которые пашут за десятерых. Как я уже говорил, разработка, по сути, командный вид спорта. Есть старая поговорка: «Если хочешь идти быстро, иди один; если хочешь идти далеко, иди с кем-то вместе». У нас бывают разработчики, которые работают за десятерых, и они быстро продвигаются вперед. Но часто это ведет к краткосрочной победе с большим количеством долгосрочных долгов. Поэтому я думаю, что настоящие 10-кратные разработчики — это те, кто делает людей вокруг себя лучше и помогает им стать более эффективными.
Если у вас есть команда из 10 человек, и вы сумеете добиться, чтобы каждый работал на 20% эффективнее, это намного ускоряет дело, особенно если эта десятка затем тоже сделает людей вокруг себя более эффективными.
Мой совет по балансу между работой и личной жизнью таков: найдите способ стимулировать людей и доверяйте им, чтобы не взваливать всё на себя. Человек создаёт себе серьёзные проблемы, когда берёт на себя ответственность, которая выходит далеко за рамки его возможностей. Моя формула: люди выгорают, например, когда чувствуют ответственность за дело, но не имеют организационных инструментов для этого или им просто не хватает 24 часов в сутках. Тогда вы в конечном итоге выгораете, потому что в конце каждого дня чувствуете, как много не сделано, и это ощущение вторгается в вашу личную жизнь.
Нужно убедиться, что имеющиеся у вас инструменты соответствуют проблемам, которые вы решаете. И развивать эти инструменты так, чтобы достичь большего при работе с другими людьми, фактически воспитывая их. В таком случае, я думаю, можно гораздо дольше избегать выгорания.
Evrone: Спасибо за беседу и спасибо за Kubernetes от всего нашего сообщества. Мы надеемся, что благодаря этому интервью мы сможем сделать наших разработчиков, а с ними и этот мир, немного лучше.
Заключение
Нам было интересно побеседовать с Джо и узнать о его ценных знаниях и опыте, о многолетней работе в качестве инженера-программиста. Мы часто используем Kubernetes при разработке продуктов для наших клиентов, а самый лучший способ получить более глубокое представление об инструменте — поговорить с одним из его создателей.
Мы также благодарим нашего друга Николая Рубанова из компании Selectel за помощь в подготовке вопросов для этого интервью.
В Evrone мы разрабатываем индивидуальные решения DevOps & Kubernetes, удовлетворяющие конкретные потребности наших клиентов. Если вам нужна помощь с проектом или идеей, или вы хотите узнать больше о наших услугах, отправьте нам сообщение, и в ближайшее время мы свяжемся с вами, чтобы узнать, чем можем помочь.