Русский
Русский
English
Статистика
Реклама

Бессерверные вычисления

Перевод Почему бессерверная революция зашла в тупик

19.10.2020 22:04:09 | Автор: admin

Ключевые моменты


  • Вот уже несколько лет нам обещают, что бессерверные вычисления (serverless) откроют новую эпоху без конкретной ОС для выполнения приложений. Нам говорили, что такая структура решит множество проблем масштабируемости. На самом деле всё иначе.
  • Хотя многие рассматривают бессерверную технологию как новую идею, её корни можно проследить вплоть до 2006 года, когда появились Zimki PaaS и Google App Engine в обоих случаях используется бессерверная архитектура.
  • Есть четыре причины, по которым бессерверная революция зашла в тупик: от ограниченной поддержки языков программирования до проблем с производительностью.
  • Бессерверные вычисления не так уж бесполезны. Отнюдь нет. Однако их не следует рассматривать как прямую замену серверов. Для некоторых приложений они могут быть удобным инструментом.

Сервер мёртв, да здравствует сервер!


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

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

Некоторые из обещаний для бессерверных моделей, несомненно, были реализованы, но не все. Далеко не все.

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

Что обещали адепты бессерверных вычислений


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

Для тех, кто не знаком с термином, вот краткое определение. Бессерверные вычисления определяют архитектуру, в которой приложения (или части приложений) выполняются по требованию в средах выполнения, которые обычно размещаются удалённо. Кроме того, бессерверные системы можно захостить у себя. В течение нескольких последних лет создание устойчивых бессерверных систем было главной заботой системных администраторов и SaaS-компаний, поскольку (как утверждается) эта архитектура предлагает несколько ключевых преимуществ по сравнению с традиционной клиент-серверной моделью:

  1. Бессерверные модели не требуют, чтобы пользователи поддерживали собственные операционные системы или даже создавали приложения, совместимые с определёнными ОС. Вместо этого разработчики создают общий код, загружают его в бессерверную платформу и наблюдают за его выполнением.
  2. Ресурсы в бессерверных фреймворках обычно оплачиваются по минутам (или даже секундам). Это означает, что клиенты платят только за то время, когда они фактически выполняют код. Это выгодно отличается от традиционной облачной VM, где машина большую часть времени простаивает, но за неё приходится платить.
  3. Проблема масштабируемости также решалась. Ресурсы в бессерверных фреймворках назначаются динамически, так что система легко справляется с внезапными всплесками спроса.

Короче говоря, бессерверные модели обеспечивают гибкие, дешёвые, масштабируемые решения. Удивительно, что мы не додумались до этой идеи раньше.

Это действительно новая идея?


На самом деле идея не нова. Концепция, позволяющая пользователям платить только за то время, когда код фактически запускается, существует с тех пор, как она была введена в рамках Zimki PaaS в 2006 году, и примерно в то же время Google App Engine предложил очень похожее решение.

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

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

Так к чему вся эта шумиха? Что ж, поскольку скорость проникновения интернета в развивающиеся страны продолжает стремительно расти, одновременно растёт спрос на вычислительные ресурсы. Например, во многих странах с быстро растущими секторами электронной коммерции просто нет вычислительной инфраструктуры для приложений на этих платформах. Вот тут-то и появляются платные бессерверные платформы.

Проблемы бессерверных моделей


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

Вот почему.

Ограниченная поддержка языков программирования


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

Считается, что бессерверные платформы поддерживают большинство основных языков. AWS Lambda и Azure Functions также предоставляют оболочку для запуска приложений и функций на неподдерживаемых языках, хотя это часто сопряжено с затратами на производительность. Так что для большинства организаций обычно это ограничение не имеет большого значения. Но вот в чём дело. Предполагается, что одно из преимуществ бессерверных моделей в том, что малоизвестные, редко используемые программы можно использовать дешевле, поскольку вы платите только за время их выполнения. А малоизвестные, редко используемые программы часто пишутся на малоизвестных, редко используемых языках программирования.

Это подрывает одно из ключевых преимуществ бессерверной модели.

Привязка к вендору


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

Самая трудная часть перехода на бессерверную модель это не вычислительные функции, которые обычно представляют собой просто фрагменты кода, а то, как приложения связаны с подключёнными системами, такими как хранилище объектов, управление идентификацией и очереди. Функции можно переместить, но остальную часть приложения нет. Это полная противоположность обещанным дешёвым и гибким платформам.

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

Производительность


Вычислительную производительность бессерверных платформ трудно измерить, отчасти потому, что вендоры стремятся сохранить информацию в тайне. Большинство утверждает, что функции на удалённых, бессерверных платформах работают так же быстро, как и на внутренних серверах, за исключением нескольких неизбежных проблем с задержкой.

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

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

Другой подход заключается в том, чтобы обеспечить регулярное выполнение критически важных для производительности программ, чтобы они оставались свежими. Этот второй подход, конечно, немного противоречит утверждению, что бессерверные платформы более экономичны, потому что вы платите только за время работы ваших программ. Облачные провайдеры внедрили новые способы сокращения холодных запусков, но многие из них требуют масштабирования до одного (scale to one), что подрывает первоначальную ценность FaaS.

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

Вы не можете запускать целые приложения


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

Точнее, это нецелесообразно с точки зрения затрат. Ваш успешный монолит, вероятно, не стоит превращать в набор из четырёх десятков функций, связанных восемью шлюзами, сорока очередями и дюжиной экземпляров БД. По этой причине serverless лучше подходит для новых разработок. Практически ни одно существующее приложение (архитектуру) нельзя перенести. Вы можете мигрировать, но придётся начинать с нуля.

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

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

Да здравствует революция?


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

Как работают и где применяются бессерверные вычисления (Function-as-a-Service)

06.05.2021 14:05:14 | Автор: admin

Serverless-вычисления и работающие на их основе решения Function-as-a-Service помогают разработчикам развивать продукты, ориентируясь на бизнес-фичи. Мы поэкспериментировали с этими технологиями и пришли к выводу, что для боевого применения существующие решения сыроваты. Пойдём по порядку.

Термин бессерверные вычисления отчасти вводит в заблуждение конечно, в основе продукта сервера остаются, но разработчикам не приходится о них заботиться. По сути своей Serverless продолжает те же идеи виртуализации, что и более ранние aaS-технологии: позволить команде сосредоточиться на коде и развитии функций. Если IaaS это абстракция оборудования, контейнеры абстракция приложений, то FaaS это абстракция бизнес-логики сервиса.

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

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

Команда не беспокоится о бэкенде и процессах деплоя, В идеальных условиях реализация новой фичи сводится к загрузке одной функции на сервер. В результате разработка двигается быстрее, Time-to-Market ползёт вниз. А в компании в целом внедрение FaaS помогает развить платформенный подход для Serverless-вычислений нужен либо пул облачных ресурсов от провайдера, либо Kubernetes-кластер.

Как это работает на практике

На рынке есть уже целый набор Serverless-платформ. Мы внимательно изучили два решения: Lambda от Amazon и KNative. Первое представляет собой проприетарный сервис для работы с облаком Amazon, второе работает поверх Kubernetes.

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

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

KNative для нас решение более интересное, поскольку оно работает поверх Kubernetes.

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

  • Event source сущность FaaS-платформы, которая взаимодействует с внешними источниками событий. Триггером может быть HTTP-запрос, сообщение от брокера сообщений, событие самой платформы

  • Broker корзина, которая принимает и хранит информацию о событиях от Event Source. Брокер может представлять собой модуль Kafka, работать в оперативной памяти и т.п.

  • Trigger подписанный на Broker компонент, который достаёт сообщения из корзины и передаёт их на исполнение в Service.

  • Service рабочая функция, изолированная бизнес-логика.

С точки зрения разработчика процесс выглядит практически так же, как с уже привычными контейнеризированными приложениями, меняется только объект: (1) написать функцию, (2) упаковать её в Docker-образ, (3) загрузить.

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

Преимущества FaaS

Лучше всего подход показывает себя, когда не требуется мгновенный ответ пользователю и когда нагрузка может колебаться от 0 до 100%:

  • Задачи, которые выполняются по расписанию. Операции экспорта/импорта в системах финансовой отчётности, учётных системах, решениях для создания резервных копий.

  • Асинхронная отправка уведомлений пользователю (push, email, СМС).

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

Какие можно выделить недостатки Serverless:

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

  2. Лучшие платформы на данный момент привязывают компанию к тому или иному облачному провайдеру будь то AWS, Microsoft Azure или Google Cloud. Решениям для Kubernetes ещё предстоит подрасти до этого уровня.

  3. FaaS это не волшебная таблетка, с которой разработчики могут забыть об инфраструктуре и просто отправлять на прод фичи. Всё равно нужно продумывать архитектуру, проектировать функции и их взаимодействие с помощью DDD. Иначе продукт превращается в массу сильно связанных между собой функций, в которых будет сложно разобраться. Разработчики не смогут деплоить такие функции и менять по отдельности. В худшем случае при обработке пользовательских запросов пользователя придётся поднимать все функции.

Наш вывод до эпохи Serverless ещё несколько лет

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

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

Подробнее..

Перевод Почему разработчики не дружат с Serverless

26.01.2021 16:05:52 | Автор: admin

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

Ролик начинается с шутки: В мире есть две вещи, которые я не понимаю, девушки и бессерверные вычисления. Я ничего не знаю об отношениях этого разработчика с девушками, но прав ли он в отношении Serverless? Давайте рассмотрим его основные критические тезисы и обсудим возможные аргументы, защищающие бессерверные вычисления.

Спойлер: я верю в пользу Serverless. Просто нужно знать, когда и как использовать эту технологию.


Критика Serverless


Основным аргументом против бессерверных вычислений является их скорость. Или хорошо известная проблема холодного старта. Холодный старт это задержка выполнения кода (может достигать до 1 секунды для таких языков, как JavaScript, Python, Go, Java, Ruby), которая происходит из-за необходимости выделения вычислительных ресурсов, извлечения кода и запуска контейнера со стороны провайдера.

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

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

Что упускают разработчики? Настоящие преимущества Serverless


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

Бессерверные вычисления это действенный способ управления IT-инфраструктурой, особенно для компаний, у которых может не быть ресурсов для покупки собственной инфраструктуры и найма специалистов, которые бы обслуживали серверы 24/7.

В нашем блоге мы уже как-то писали о Serverless в подробном тексте. Также предлагаем вам опробовать бессерверные вычисления с помощью сервиса Облачные функции. На странице продукта в Панели управления уже есть несколько примеров использования Serverless, а также шаблоны кода.

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


В большинстве случаев, с которыми я сталкивалась, использование бессерверных вычислений на порядок дешевле, чем использование ресурсов, размещенных на собственном хостинге. Это справедливо не только для стоимости вычислительных мощностей как таковых. Более дешевым Serverless делает также то, что решение экономит время, необходимое для работы, масштабирования и обслуживания инфраструктуры. Вы ощутите реальную экономию средств, потому что вам не придется нанимать команду штатных системных инженеров. Хорошие специалисты стоят значительно дороже бессерверных вычислений.

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

Холодный старт можно нивелировать


Возвращаясь к вопросу о времени выполнения кода, проблема холодного запуска во многом от зависит от того, как вы пишете код и настраиваете Serverless.

В целом, существует немало способов смягчить холодный запуск, подогрев его. Так, можно запускать функции с некоторой периодичностью, чаще запускать сервис или держать часть контейнеров запущенными все время (если это позволяет провайдер). Эти действия обеспечат необходимую теплую среду для запуска функций.

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

Какая задержка приемлема для ваших рабочих нагрузок?


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

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

Бессерверные вычислений это про NoOps и масштабируемость


Serverless позволяет вам быстрее генерировать пользу для бизнеса, поскольку провайдер облачных услуг берет на себя большую часть IT-операций. Выделяет вычислительные мощности, масштабирует кластеры под требуемую нагрузку, следит за безопасностью и обновлениях, заботится о целостности оборудования и так далее. Так как головной боли, связанной с управлением инфраструктурой, больше нет, можно сконцентрироваться на работе с клиентами. Разве это главное в конце концов?

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

В каких случаях использовать бессерверные вычисления особенно полезны


Представьте, что вы основали стартап. Сначала вам может не понадобиться значительная инфраструктура, и у вас может быть только один разработчик. Парадигма Serverless позволяет вам начать с малого и автоматически масштабировать ресурсы по мере роста вашего бизнеса с помощью модели затрат Pay-as-you-go (плата за реальное пользование).

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

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

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

Скорость выполнения кода против скорости циклов разработки


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

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

Недостатки Serverless, которые не были упомянуты в видео


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

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

  1. Существует риск вендор-лока. Провайдеры делают свои услуги настолько удобными и экономичными, что вы рискуете привязаться к конкретному поставщику облачных услуг.
  2. При сравнении бессерверных вычислений и физических ресурсов, размещенных на собственном хостинге, в первом случае у вас меньше контроля. Например, вы не можете подключиться по SSH к инфраструктуре, чтобы выполнить некоторую настройку вручную, также есть ограничения по типу инстансов.
  3. Если ваши политики безопасности и требования хранения информации не позволяют обрабатывать данные на общем клиенте в облаке, бессерверные вычисления могут вам не подойти.
  4. Дробление вашей ИТ-инфраструктуры на автономные микросервисы позволяет сократить циклы выпуска, но это создает проблему контроля и управления всеми микросервисами.

Вывод


В целом, использовать новые парадигмы в IT, такие как бессерверные вычисления или другие облачные сервисы, в той же логике, что и привычные нам домашние on-premises технологии, едва ли самая хорошая идея. Когда вы занимаетесь прямым копипастгом рабочих процессов с физической инфраструктуры в облако, вы теряете многие преимущества облачных сервисов, если вообще не лишаете их смысла.

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

С моей точки зрения, мы не должны говорить о Serverless (как, впрочем, и о других IT-решениях) категорично, рассматривая только один аспект работы и игнорируя остальные. Бессерверные вычисления имеют смысл. Если вы знаете, когда и как их использовать.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru