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

В отпуске удалось записать подкаст с коллегой, Алексеем, который крепко в теме UX и UI. Мы касаемся темы удовлетворенности при проектировании пользовательских интерфейсов и не только. Подкаст под катом, приглашаю послушать.

Привет, Хабр! Сегодня поговорим о принципах асинхронной работы с сообщениями и их очередями в распределенной и бессерверной архитектуре. У Amazon для этого есть веб-сервисы Simple Notification Service (SNS) и Simple Queue Service (SQS): они позволяют обмениваться сообщениями между микросервисами. В этой статье разберём, чем они отличаются, что могут и какие есть ещё предложения на этом рынке.

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

Ежегодный AWS re:Invent, проходивший в конце 2021 года, принёс массу новостей про бессерверные технологии Янашёл самые интересные: и под катом мы поговорим про запуск функций на Graviton2, новых возможностях для машинного обучения, перенос разработки в облако и визуальный редактор для step-функций.

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

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

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

Зачастую возникает вопрос: «Как надежно и безопасно внедрять секреты в бессерверные приложения?»

Привет, Хабр! Меня зовут Антон Черноусов, я куратор хаба Serverless. В этом посте я расскажу, что интересного тут было про бессерверные технологии за год. Разложил их по нескольким группам и выстроил от теории к практике: сначала посты про саму технологию, затем про старт работы, про инструменты, про важные особенности, и в конце сделал подборку интересных кейсов.

Под катом 20+ публикаций про Serverless за 2021 год.

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

При работе с Serverless есть задачи, для которых базовой функциональности облачных платформ не хватает: использование бессерверных функций со сторонними API, локальная отладка приложения, объединение возможностей нескольких фреймворков. В ответ на эти вызовы появились специальные инструменты — бессерверные фреймворки. Они упрощают запуск проекта, повышают уровень защищённости приложения, а также позволяют быстро внести изменения в стек или архитектуру.

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

Наша исходная задача заключалась в том, чтобы попытаться ответить на ряд актуальных вопросов, в частности: когда целесообразнее использовать AWS Lambda, а когда сервисы AWS EC2. А самое главное — разобраться, какие параметры играют в данном случае наибольшую роль.

Холодные запуски могут оказаться губительными для производительности AWS Lambda, особенно если вы создаёте клиентоориентированное приложение, которое должно работать в режиме реального времени. Представьте себе, что пользователь отправил приложению запрос, а ваша функция AWS Lambda ещё не запущена. В таком случае система AWS должна будет сначала развернуть ваш код и запустить новый контейнер — и только после этого выполнит запрос. Соответственно, выполнение запроса может занять гораздо больше времени: Lambda-функция начнёт работать только тогда, когда для неё будет готов контейнер.

При работе с бессерверными функциями разработчикам необходимо подстраиваться под поддерживаемые провайдером языки программирования и библиотеки. Эта проблема решается с помощью бессерверных контейнеров: они позволяют запускать в облаке собственные контейнеры из образа, и у каждого своя изолированная вычислительная среда. В результате мы дополняем стандартные бонусы serverless-подхода, такие как масштабирование и Pay-as-you-go, гибкой настройкой окружения. В этой статье я расскажу, чем бессерверные контейнеры отличаются от бессерверных функций и что сейчас предлагают основные облачные провайдеры. 

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

Бессерверные вычисления применяются в широком спектре сценариев — от решения краткосрочных задач до создания ориентированных на пользователей приложений. AWS Lambda — наиболее проработанная и широко используемая FaaS-платформа, основанная на модели «функция как услуга», но далеко не единственная. Распространение таких систем, как Azure Functions и Google Cloud Functions, также идёт впечатляющими темпами. Сегодня бессерверная экосистема вышла уже далеко за пределы модели FaaS и теперь включает десятки сервисов, помогающих разработчикам создавать более быстрые и динамичные приложения. Четверть клиентов Amazon CloudFront уже используют бессерверные периферийные вычисления, а также применяют функции AWS Step Functions для управления прикладной логикой самых разных распределённых компонентов.

В этом отчёте мы расскажем вам о важнейших инсайтах и трендах бессерверного ландшафта.

Calvin — это подход к фиксации транзакций, который позволяет сохранить принципы ACID в распределенных системах без потери производительности. Впервые он был упомянут в работе Йельского университета в 2012 году. Calvin хорошо вписывается в целый класс бессерверных СУБД. Мы знаем как минимум две системы, в которых он используется: Yandex Database и FaunaDB, но, возможно, есть и другие.

Основная претензия при работе с serverless — время холодного старта, которым нельзя управлять «из коробки». Если функция стартует впервые за последние 5–25 минут, скорее всего запуск будет долгим — сотни миллисекунд. Причём статически типизированные языки имеют в разы большее время холодного запуска, которое может достигать нескольких секунд. Разработчики решают это на этапе загрузки своего кода, и им в помощь есть целые библиотеки. Например, они позволяют вызвать функцию заранее. Эти способы действительно сокращают время, но не устраняют проблему полностью и могут работать нестабильно. Параллельно этот вопрос пытаются решить и сами облачные провайдеры. Сегодня поговорим о том, как с холодным стартом справляются и те и другие.

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

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

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

Сегодня бо́льшая часть production-решений продолжает резервировать собственные мощности под базы данных. Да, это надёжно и привычно, но тем не менее всё больше проектов обращается к бессерверным инструментам, в том числе и к базам данных. Создатели находят этим инструментам применение в распределённых приложениях и микросервисах, где важна скорость разработки и возможность масштабирования. 

Бессерверные базы данных развивались последние несколько лет параллельно с бессерверными вычислениями, и сейчас можно условно выделить два типа СУБД: адаптирующие популярные базы данных под бессерверное использование и разработанные под бессерверный режим. В этой статье я расскажу об их особенностях и дам примеры применения.

Не думаю, что многие разработчики сегодня используют CGI-скрипты и старый добрый PHP. Поэтому у каждого из нас есть любимый фреймворк, с помощью которого мы и создаём свои веб-приложения. Чем бы мы ни занимались — составлением стандартного юридического контракта или съёмками голливудского блокбастера, — всегда полезно начать с какого-нибудь шаблона. Фреймворк придаёт структуру вашему приложению и избавляет вас от необходимости снова и снова изобретать велосипед. Это может быть навороченная платформа — своего рода конструктор, в котором есть всё, что нужно, даже батарейки (Rails, Django, Spring Boot, Nest), — либо минималистичный, но удобный фреймворк, работающий по принципу «тяп-ляп — и готово» (например, Flask или Express).

Мы не любим отвлекаться от текущей работы, копаться в трекере задач и почте, чтобы найти нужный тикет или письмо от клиента. Нас беспокоят пропущенные напоминания и недоступные логи. Чат-боты и боты для поддержки процессов разработки популярны у разработчиков именно потому, что избавляют нас от нелюбимой рутины. Боты помогают нам в DevOps-трансформации.

Для разработки ботов удобно использовать serverless-технологии. Одно из преимуществ при работе с приложениями облачного бота, которые тоже размещены в облаке, — моментальный доступ к ним. В докладе на DevopsConf 2021 я подробно рассказал о концепции СhatOps и о том, какие из serverless-технологий стоит взять на вооружение уже сейчас. Кажется, что СhatOps и serverless созданы друг для друга.

Бессерверные вычисления (или serverless-технологии, как их иногда называют) — это перспективная технологическая модель облачных вычислений, появившаяся на горизонте прикладной разработки и архитектуры в последние годы. Именно благодаря стремлению воспользоваться огромным потенциалом бессерверных фреймворков многие крупные рыночные игроки оказались увлечены общим бумом облачных сервисов. Такие гиганты программной отрасли, как Google, Microsoft, IBM и Amazon, уже предлагают своим клиентам перенести локальные бизнес-процессы и обеспечить операционную эффективность на флагманских бессерверных платформах, таких как AWS Lambda и Azure Functions.

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

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