[Отладка, Микросервисы, Serverless] Руководство по отладке бессерверных приложений (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Эволюция бессерверной архитектурыВсе началось в 1953 году, когда компания IBM выпустила свой первый коммерческий компьютер. И вот сегодня мы обсуждаем бессерверную архитектуру. За прошедшие годы вычислительная техника не только совершила настоящую революцию в том, как строится работа современных компаний, – но и претерпела огромные преобразования сама по себе.После ряда успешных (и не очень) проектов по развертыванию фреймворков на корпоративных инфраструктурах и в облаке, была сформулирована концепция фреймворка FaaS (Function as a Service). Его задача – обеспечить запуск приложений в контейнерах без сохранения состояния. Это дает разработчикам возможность сконцентрироваться на самом коде, а не на управлении сложной инфраструктурой и связанными с ней ресурсами. Это привело к изобретению бессерверной архитектуры, ориентированной исключительно на исполнение двоичных файлов приложений, при этом все необходимые ресурсы управляются сторонним провайдером и принадлежат ему. По своей сути бессерверная архитектура позволила предприятиям не только сильнее сосредоточиться на разработке основных приложений, но и существенно снизить накладные расходы.Однако платформы бессерверных вычислений не только позволили разработчикам быстрее создавать и развертывать приложения, но и привнесли ряд новых проблем с их отладкой по сравнению с традиционными платформами. В этой статье мы рассмотрим методы, проблемы и популярные инструменты отладки, используемые в бессерверной инфраструктуре.Что такое отладка в бессерверной среде?Поскольку бессерверная архитектура все еще находится на стадии становления, подходы и инструменты, которые гладко встраиваются в FaaS-платформы и при этом позволяют осуществлять постоянный сбор данных, также непрерывно совершенствуются. Так как бессерверные приложения используют всевозможные функции, обращающиеся к разным источникам событий и сервисов, отладка сводится, по сути, к тестированию одного или нескольких таких компонентов с акцентом на безопасность работы приложения.В ходе отладки в бессерверном режиме возникает множество уникальных проблем. К ним относятся: высокая степень распределенности компонентов, изначальное отсутствие средств удаленной отладки, эфемерность дизайна контейнеризованных приложений, а также отсутствие фреймворков для локальной установки. Кроме того, при использовании множества компонентов в рамках одного приложения появляется несколько возможных точек отказа, которые также необходимо устранить при отладке. Более того, бессерверные приложения по своей архитектуре сложны, а входящие в их состав компоненты слабо связаны, что повышает важность процесса отладки и делает его более сложным.Различия в отладке бессерверных и монолитных приложенийНа фоне того, что монолитные приложения постепенно теряют популярность и уступают бессерверным приложениям, с точки зрения простоты отладки они безусловно доминируют. Отладка монолитных приложений проводится локально, в их собственной интегрированной среде разработки (IDE), при этом разработчик создает точку останова на проверяемой строке кода. Поскольку IDE-системы поставляются уже с готовым режимом отладки – это все, что требуется от разработчиков для выявления ошибок в коде. В бессерверной архитектуре, наоборот, наиболее популярным методом отладки является логирование. Разработчики отслеживают и записывают все действия сервиса в лог-файлы – и таким образом получают представление о поведении приложения.В случае монолитных приложений все проблемы можно оттестировать и устранить в локальной среде. Точки отказа обычно возникают на уровне пользовательского интерфейса, серверной части или базы данных. Бессерверные приложения, наоборот, включают в себя множество распределенных, связанных друг с другом компонентов. Поэтому в локальной среде сложно настроить бессерверные приложения и устранить все проблемы, связанные с их работой.Кроме того, монолитные приложения поддерживают удаленную отладку. Вы можете подключить IDE к удаленным серверам, дав разработчикам привилегированный доступ. Несмотря на то, что это в принципе возможно, применять этот метод целесообразно только в тех случаях, когда локальное моделирование вряд ли даст результаты. Бессерверные приложения по природе своей не поддерживают удаленную отладку в силу отсутствия доступа на уровне ОС и сервера.Притом что организация процесса тестирования и устранения проблем может потребовать определенных усилий, для монолитного приложения это обычно сделать проще, поскольку каждая задача и функция выполняются в рамках какого-то одного процесса. С другой стороны, бессерверные приложения требуют перехода через границы процессов, при этом зависимость между компонентами обычно очень слаба. Это делает отладку непростой задачей, включающей в себя сбор и анализ огромных объемов данных.Типы отладочных фреймворков для бессерверных приложенийБессерверные приложения эфемерны по своей природе и управляются событиями. Это означает, что бессерверные функции могут обращаться к различным сервисам в разные моменты времени, по мере необходимости. В итоге, несмотря на то, что некоторые сервисы можно смоделировать локально, отладка таких приложений, как правило, включает полную проверку имеющихся логов.Таким образом, отладочные фреймворки для бессерверных приложений основываются на двух различных подходах с использованием AWS Lambda:
- Локальная отладка бессерверных приложений
- Отладка бессерверных приложений для облака
Локальная отладка бессерверных приложенийПри разработке ПО важнейшая часть отладки происходит при локальном запуске. Модель бессерверных приложений (SAM) – это решение, которое позволяет разработчикам запускать свои приложения локально на бессерверной платформе Amazon на базе AWS Lambda. В пакет решения входит два компонента: спецификация шаблона (SAM Template Specification) и интерфейс командной строки (SAM Command Line Interface). Спецификация шаблона позволяет определить приложение с помощью прав доступа, событий, API-интерфейсов и функций. При этом интерфейс командной строки позволяет вызывать функции локально, осуществлять пошаговую отладку функций, а также упаковывать и развертывать приложения в облаке. Здесь можно ознакомиться с полным руководством по использованию AWS SAM для локальной отладки на платформе AWS Lambda.Отладка бессерверных приложений для облакаПосле того как вы развернули приложение в облаке, вам необходимо понять, какие проблемы возникают при подключении функций к сервисам. Некоторые из этих подключений обычно невозможно смоделировать в локальной среде тестирования, поэтому требуется разработка процедуры для тестирования в реальном времени. Вот процедура, которая используется при тестировании в реальном времени для приложения, развернутого в облаке AWS:
- Первый этап – тестирование API-шлюза. Вот некоторые из наиболее популярных инструментов для тестирования конечных точек API и шлюзов: SoapUI, Postman и Curl.
- Второй этап – тестирование функций AWS Lambda непосредственно в AWS-консоли, без использования источника событий. Этот шаг поможет вам с легкостью диагностировать проблемы в работе Lambda-функций при первом развертывании приложения. На этом этапе также потребуется создание тестовых событий, эмулирующих сервисы AWS.
- На следующем этапе изучается поведение приложения с помощью логов AWS CloudWatch. Функции AWS Lambda по умолчанию настроены на отправку логов в CloudWatch. Затем решение создает для каждой функции класс LogGroup, включающий все события, вызываемые этой функцией. Еще для отслеживания событий приложений можно использовать такие решения как Splunk и ELK.
- На заключительном этапе вы можете провести анализ работы и отладку приложения с помощью AWS X-RAY. Это решение обеспечивает сквозной мониторинг событий и создает графическую визуализацию всех компонентов приложения. Именно эти возможности делают его идеальным инструментом отладки не только в процессе разработки приложений, но и в ходе промышленной эксплуатации.
Популярные средства отладки бессерверных приложенийВы, конечно, можете отлаживать свое приложение с помощью встроенных средств, таких как CloudWatch и X-RAY, – но все же это ручной и весьма утомительный процесс, требующий использования сразу нескольких решений. Однако существуют и самостоятельные инструменты для отладки бессерверных приложений. Они существенно упрощают процесс благодаря интегрированному интерфейсу и удобному процессу очистки всех используемых функций и сервисов. Вот некоторые из этих инструментов:Faasly.ioFaaSly дает комплексное представление обо всех ваших запросах как на уровне функций, так и на уровне вызовов, используя единую панель. Кроме того, он включает интерактивную карту сервиса (Service Map), выполняющую функцию диспетчерского центра и позволяющую быстро выявить узкие места в работе приложения и легко устранить их.Встроенная система безопасности Благодаря глубокой интеграции с таким решением корпоративного класса как Envoy, можно достичь высокой степени защиты и соответствия нормативным требованиям благодаря возможности перехватывать каждый сетевой запрос, отправляемый из рабочего приложения AWS Lambda. Если ваши функции в какой-то момент будут скомпрометированы, ваши настоящие учетные данные AWS всегда останутся в безопасности.Мониторинг без изменения кода Вы можете мгновенно оценить работоспособность своих распределенных систем в режиме реального времени, даже не прикасаясь к отлаживаемому коду.AWS CloudwatchAWS CloudWatch – это мощная платформа для мониторинга инфраструктуры и приложений. Она обеспечивает прозрачное представление данных через единый интерфейс, сбор метрик с низким уровнем задержки, возможности анализа данных логов и данных по загруженности ресурсов. CloudWatch также ведет сбор данных, предоставляя достоверную информацию о производительности системы, уровне оптимизации ресурсов, а также работоспособности вашего приложения. Удобные информационные панели, расположенные на одном экране, дают доступ к информации о запущенных сервисах, приложениях и ресурсах.Инструменты SLS-DevИнструментарий Serverless Development Tools – это открытый фреймворк с набором инструментов для разработчиков бессерверных платформ и приложений. Этот набор инструментов следует парадигме «cloud-native», что способствует ускоренному развитию инноваций и их внедрению в промышленную эксплуатацию. Поскольку этот набор подразумевает оплату по мере использования, вы платите только за фактическое время работы и тестирования своего приложения на платформе. Притом что базовая версия включает почти весь критически важный функционал инструментария, расширенная версия под названием SLS-DevTools Guardian помогает оперативно обнаруживать проблемы по мере их возникновения и проводить отладку в режиме реального времени.LumigoLumigo – это интерфейс для мгновенного доступа к логам и устранения неполадок бессерверных приложений. Платформа предлагает возможности сквозного логирования и мониторинга, что позволяет разработчикам глубже разобраться в тонких моментах выполнения функций и изолировать первопричину проблем в работе приложения. В этот инструмент входит функционал, позволяющий идентифицировать критический путь работы приложения и его точки отказа. Это позволяет повысить эффективность приложения благодаря сокращению задержек.DashbirdЕсли ваше приложение разработано на базе AWS Lambda, то Dashbird должен стать одним из ваших самых любимых инструментов отладки и оптимизации кода. Этот инструмент нацелен на обнаружение ряда распространенных сбоев в работе AWS Lambda, включая проблемы с памятью, тайм-ауты, ошибки времени выполнения, исключения и ошибки конфигурирования. Dashbird также оперативно предупредит вас о сбоях через Slack или по электронной почте и поможет сохранить непрерывную доступность сервиса. Помимо этого, можно интегрировать Dashbird с AWS X-RAY и получать информацию обо всех событиях и вызовах функций.SignalFXSignalFx – это решение для облачного мониторинга, способное интегрироваться с основными поставщиками услуг, включая Google Cloud Functions, Azure Functions и AWS Lambda. Этот инструмент обеспечивает мониторинг производительности в режиме реального времени и непрерывную прозрачность для всех ваших бессерверных функций. Благодаря обширному списку функций, включающему метрики с малой задержкой, оптимизацию затрат, обнаружение холодного запуска и мониторинг времени выполнения, SignalFx неуклонно набирает популярность в сообществах разработчиков.Заключительные мыслиНесмотря на то, что бессерверные технологии еще сравнительно молоды, они уже начали трансформировать способы доставки и предоставления приложений. Несмотря на растущую популярность, отладка бессерверных приложений все еще находится в процессе становления, поскольку большинство доступных инструментов пока не интегрировано с другими сервисами и комплексное тестирование на данный момент не реализуемо.В этой статье мы рассмотрели различные способы выполнения бессерверной отладки как при локальном внедрении, так и в облаке. Мы также рассмотрели ряд наиболее популярных и простых инструментов для отладки бессерверных приложений.По мере более широкого распространения бессерверных вычислений, мы уже в ближайшие годы наверняка увидим ряд новых подходов и инструментов для отладки. На текущий момент мы рекомендуем использовать инструменты, упомянутые выше. Будем рады узнать, для каких сценариев вы используете бессерверные технологии.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Prasanna Venkatesh
===========Похожие новости:
- [Программирование, Совершенный код, C++, Отладка, C] Как подключить содержимое любых файлов для использования в коде C / C++
- [Высокая производительность, Микросервисы] Сравниваем производительность REST и gRPC (перевод)
- [Системное администрирование, Программирование, DevOps, Микросервисы, Serverless] Интересное о Serverless: хабрастатьи о применении, инструментах, кейсах и инструкциях для первого свидания
- [Клиентская оптимизация, Разработка мобильных приложений, Микросервисы] Платформа по работе с обращениями клиентов в «Пятёрочке»
- [.NET, Visual Studio, Отладка, Разработка под Windows] Гарантированная локализация/русификация консоли Windows
- [Ruby, Ruby on Rails, Администрирование баз данных, Микросервисы] Синхронизация баз данных между монолитом и микросервисами с помощью Kafka. Наше решение
- [IT-инфраструктура, Управление продуктом, Микросервисы] Как быстро и легко интегрироваться с Active Directory
- [Системное администрирование, *nix, DevOps, Микросервисы, Kubernetes] Ломаем и чиним etcd-кластер
- [Разработка веб-сайтов, Разработка мобильных приложений] 10 инструментов для разработки, которые вам стоит попробовать (перевод)
- [Разработка игр, Реверс-инжиниринг, Игры и игровые приставки] Как я сократил время загрузки GTA Online на 70% (перевод)
Теги для поиска: #_otladka (Отладка), #_mikroservisy (Микросервисы), #_serverless, #_serverless, #_otladka (отладка), #_logirovanie (логирование), #_lambda, #_faas, #_otladka (
Отладка
), #_mikroservisy (
Микросервисы
), #_serverless
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:07
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Эволюция бессерверной архитектурыВсе началось в 1953 году, когда компания IBM выпустила свой первый коммерческий компьютер. И вот сегодня мы обсуждаем бессерверную архитектуру. За прошедшие годы вычислительная техника не только совершила настоящую революцию в том, как строится работа современных компаний, – но и претерпела огромные преобразования сама по себе.После ряда успешных (и не очень) проектов по развертыванию фреймворков на корпоративных инфраструктурах и в облаке, была сформулирована концепция фреймворка FaaS (Function as a Service). Его задача – обеспечить запуск приложений в контейнерах без сохранения состояния. Это дает разработчикам возможность сконцентрироваться на самом коде, а не на управлении сложной инфраструктурой и связанными с ней ресурсами. Это привело к изобретению бессерверной архитектуры, ориентированной исключительно на исполнение двоичных файлов приложений, при этом все необходимые ресурсы управляются сторонним провайдером и принадлежат ему. По своей сути бессерверная архитектура позволила предприятиям не только сильнее сосредоточиться на разработке основных приложений, но и существенно снизить накладные расходы.Однако платформы бессерверных вычислений не только позволили разработчикам быстрее создавать и развертывать приложения, но и привнесли ряд новых проблем с их отладкой по сравнению с традиционными платформами. В этой статье мы рассмотрим методы, проблемы и популярные инструменты отладки, используемые в бессерверной инфраструктуре.Что такое отладка в бессерверной среде?Поскольку бессерверная архитектура все еще находится на стадии становления, подходы и инструменты, которые гладко встраиваются в FaaS-платформы и при этом позволяют осуществлять постоянный сбор данных, также непрерывно совершенствуются. Так как бессерверные приложения используют всевозможные функции, обращающиеся к разным источникам событий и сервисов, отладка сводится, по сути, к тестированию одного или нескольких таких компонентов с акцентом на безопасность работы приложения.В ходе отладки в бессерверном режиме возникает множество уникальных проблем. К ним относятся: высокая степень распределенности компонентов, изначальное отсутствие средств удаленной отладки, эфемерность дизайна контейнеризованных приложений, а также отсутствие фреймворков для локальной установки. Кроме того, при использовании множества компонентов в рамках одного приложения появляется несколько возможных точек отказа, которые также необходимо устранить при отладке. Более того, бессерверные приложения по своей архитектуре сложны, а входящие в их состав компоненты слабо связаны, что повышает важность процесса отладки и делает его более сложным.Различия в отладке бессерверных и монолитных приложенийНа фоне того, что монолитные приложения постепенно теряют популярность и уступают бессерверным приложениям, с точки зрения простоты отладки они безусловно доминируют. Отладка монолитных приложений проводится локально, в их собственной интегрированной среде разработки (IDE), при этом разработчик создает точку останова на проверяемой строке кода. Поскольку IDE-системы поставляются уже с готовым режимом отладки – это все, что требуется от разработчиков для выявления ошибок в коде. В бессерверной архитектуре, наоборот, наиболее популярным методом отладки является логирование. Разработчики отслеживают и записывают все действия сервиса в лог-файлы – и таким образом получают представление о поведении приложения.В случае монолитных приложений все проблемы можно оттестировать и устранить в локальной среде. Точки отказа обычно возникают на уровне пользовательского интерфейса, серверной части или базы данных. Бессерверные приложения, наоборот, включают в себя множество распределенных, связанных друг с другом компонентов. Поэтому в локальной среде сложно настроить бессерверные приложения и устранить все проблемы, связанные с их работой.Кроме того, монолитные приложения поддерживают удаленную отладку. Вы можете подключить IDE к удаленным серверам, дав разработчикам привилегированный доступ. Несмотря на то, что это в принципе возможно, применять этот метод целесообразно только в тех случаях, когда локальное моделирование вряд ли даст результаты. Бессерверные приложения по природе своей не поддерживают удаленную отладку в силу отсутствия доступа на уровне ОС и сервера.Притом что организация процесса тестирования и устранения проблем может потребовать определенных усилий, для монолитного приложения это обычно сделать проще, поскольку каждая задача и функция выполняются в рамках какого-то одного процесса. С другой стороны, бессерверные приложения требуют перехода через границы процессов, при этом зависимость между компонентами обычно очень слаба. Это делает отладку непростой задачей, включающей в себя сбор и анализ огромных объемов данных.Типы отладочных фреймворков для бессерверных приложенийБессерверные приложения эфемерны по своей природе и управляются событиями. Это означает, что бессерверные функции могут обращаться к различным сервисам в разные моменты времени, по мере необходимости. В итоге, несмотря на то, что некоторые сервисы можно смоделировать локально, отладка таких приложений, как правило, включает полную проверку имеющихся логов.Таким образом, отладочные фреймворки для бессерверных приложений основываются на двух различных подходах с использованием AWS Lambda:
=========== Источник: habr.com =========== =========== Автор оригинала: Prasanna Venkatesh ===========Похожие новости:
Отладка ), #_mikroservisy ( Микросервисы ), #_serverless |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:07
Часовой пояс: UTC + 5