[Виртуализация, DevOps, Облачные сервисы] По-прежнему ли актуальны контейнеры? (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
При обсуждении создания нового проекта или разработке «дорожной карты» уже существующего варианты способов запуска рабочих нагрузок никогда не были столь обширными. Мы живём в эпоху, избалованную выбором платформ — можно выбирать между open-source-инструментами, платными сервисами, enterprise-продуктами и кучей всего ещё. Из-за этого принять решение о выборе стало сложнее — шансы получить «паралич выбора» растут с увеличением вариантов. В таких условиях справедливо будет задаться вопросом: по-прежнему ли контейнеры являются разумным выбором на текущий момент и на будущее, или мы уже их переросли? Чтобы ответить на этот вопрос, нужно рассмотреть альтернативы и сравнить их с контейнерами.
Serverless
Следующим логическим шагом после контейнеров являются serverless-решения. Такие сервисы, как AWS Lambda и Google Cloud Functions упрощают эксплуатацию serverless-приложений, особенно тех из них, которые по своей природе управляются событиями. Если учесть простоту работы с фреймворками приложений наподобие Serverless Framework, мы получаем простой рабочий процесс с учётом требований разработчиков, позволяющий перейти от идеи к продакшену за очень короткое время. Этот рабочий процесс может замечательно подойти для прототипирования API или быстрой разработки новых функций уже существующих продуктов. Одна из самых сильных сторон архитектуры serverless (особенно при запуске приложений у поставщика публичных облачных услуг наподобие AWS) заключается в том, что вы платите только за активно используемые вычислительные ресурсы; то есть за простой системы вы не платите. В перспективе это может обеспечить серьёзную экономию средств по сравнению с архитектурой «всегда включено», но только в определённых условиях. Существует порог, после которого стоимость выполнения приложения в serverless-среде становится выше, а производительность ниже по сравнению с таким же приложением, запущенным в выделенной ВМ, где вы платите не за вызов приложения, а почасовой тариф. Давайте сравним serverless с контейнерами:
ПЛЮСЫ:
- Быстрый процесс разработки
- Потенциальная экономия средств (до определённого порога)
- Простота поддержки
МИНУСЫ:
- Парадигму разумно использовать только для определённых нагрузок
- Часто имеют ограничение по максимальному времени, долговременные задачи требуют особого внимания
- Стоимость сильно зависит от использования
- Привязана к небольшому подмножеству продуктов, нелегко портировать
Platform-As-A-Service (PaaS)
Похожи на serverless, но имеют свои уникальные особенности Platform-As-A-Service (PaaS) наподобие Heroku и CloudFoundry. Обычно PaaS отличаются от serverless тем, что предназначены для «постоянно работающих» сервисов, а не для управляемых событиями, однако похожи на них тем, что аналогично serverless обеспечивают удобные разработчикам рабочие процессы. Внутри большинство подобных решений на самом деле выполняет ваш код в контейнерах, но большая их часть абстрагирована от пользователя, поэтому зачастую они позиционируются как «buildpacks» — готовые контейнеры, обладающие определёнными особенностями или установленными в них языкозависимыми пакетами. Именно это абстрагирование и составляет удобство продуктов PaaS — все хлопотные аспекты выполнения приложения в продакшене абстрагируются от пользователя. Однако это может быть и одним из недостатков PaaS: могут возникнуть сложности с высвобождением приложений из платформ PaaS и перемещением их на другую платформу при необходимости. Кроме того, на некоторых не полностью сформировавшихся платформах нативная интеграция с внешними сервисами (базами данных, кэшами, очередями и т.п.) может быть ограниченной или отсутствовать вовсе, что значительно ограничивает варианты архитектуры. К тому же за абстрагирование и простоту использования приходится платить: платформы PaaS обычно дороже, чем такие IaaS в стиле «сделай сам», как AWS или GCP.
ПЛЮСЫ:
- Простота использования
- Удобный для разработчиков рабочий процесс
- Практически нулевые эксплуатационные издержки
МИНУСЫ:
- Привязка к поставщику
- Цена
- Малая доступность интеграции
Решения No-Code
Решения No-code становятся популярнее как средство для быстрого развития стартапа, особенно среди не обладающих техническими знаниями организаторов. Возможность создания целой веб-платформы без необходимости изучать код привлекает, а для тех, кто не умеет кодить, она даже необходима. Современные решения no-code размывают границы пересечения бизнес-процессов и ПО; бизнес-логику, на разработку которой в прошлом могли тратиться недели, теперь можно создать за считанные минуты или часы на платформе no-code. Повторюсь, для не обладающих техническими знаниями людей или групп это может быть потрясающим успехом, но относится ли вообще такой подход к сфере разработки ПО? С точки зрения парадигмы решения no-code похожи на serverless тем, что обе концепции работают в модели управления на основе событий, однако решения no-code обладают одним серьёзным изъяном, которого нет у других платформ из нашего списка: чрезмерной привязкой к поставщику решения. На данный момент мне неизвестна ни одна платформа, позволяющая перенести приложение no-code с одной платформы на другую. Если вы решите писать своё базовое приложение в Microsoft Power Automate или Zoho Creator, то там вы и будете оставаться, пока не перепишете его на чём-то другом.
ПЛЮСЫ:
- Очень низкий порог вхождения
- Низкая стоимость
- Могут вносить свой вклад люди, не обладающие техническими знаниями
МИНУСЫ:
- Чрезмерная привязка к поставщику
- Некоторые платформы обладают ограниченной функциональностью
- Негибкая парадигма
Контейнеры
Так где же место контейнеров среди всех этих технологий? Я склонен воспринимать контейнеры как фундаментальные строительные блоки архитектуры, как мельчайшие части приложения, которые не имеет смысла разделять. Вне зависимости от того, эксплуатируете ли вы внутри контейнеров микросервисы или целый монолит, контейнер должен представлять собой наименьший объём кода, который можно развернуть с сохранением его функциональности. На самом простейшем уровне контейнеры — это просто подмножество функций ядра. Такие функции, как изолирование ресурсов, сетевой тротлинг и т.п., являющиеся частью ОС Linux, преобразованы таким образом, чтобы людям было проще ими пользоваться. Вполне можно запустить процесс и управлять им с помощью cgroups, виртуальных сетей, iptables и прочих функций, имитирующих контейнер Docker, однако такие приложения, как Docker и Podman обеспечивают удобство пользования этими функциями, чтобы не приходилось делать всё это вручную. Именно это использование функций ядра обеспечивает контейнерам портируемость. При наличии машины под Linux с достаточно современным ядром вы без проблем сможете запустить практически любой контейнер. Однако за такую простоту нужно платить цену, и этой ценой является сложность эксплуатации. Для разворачивания продакшена недостаточно просто развернуть один контейнер на голой ВМ. Для «правильной» реализации вам понадобится некое управление контейнерами, повышающее сложность и эксплуатационные затраты. Однако несмотря на повышение сложности, контейнеры компенсируют его своей гибкостью и портируемостью.
ПЛЮСЫ:
- Гибкость, портируемость
- Архитектура «всегда включено» позволяет использовать различные типы парадигм
- Простота локального тестирования и разработки
МИНУСЫ:
- Для продакшена требуется управление контейнерами
- Использование вычислительных ресурсов в режиме «всегда включено» может стоить больше, чем serverless, однако это зависит от нагрузки
- Для подготовки к продакшену требуется больше работы
Заключение
Хотя ваш личный выбор может сильно зависеть от приложений и нагрузок, я делаю очень простой вывод: контейнеры по-прежнему очень актуальны и так будет продолжаться очень долго. Несмотря на повышение сложности, их портируемость и уровень контроля позволяют инженерам делать именно то, что им нужно, без необходимости реверс-инжиниринга решения на основании чего-то типа Heroku.
Используя наши облачные серверы вы сможете без проблем разворачивать свои контейнеры Docker. Это только одна из миллионов задач, которую можно воплотить вместе с Маклаудом!
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
оригинал
===========
Источник:
habr.com
===========
===========
Автор оригинала: Peter Christian Fraedrich
===========Похожие новости:
- [Интервью, Serverless] Погружение в Serverless. По следам протокола S3
- [PostgreSQL, Java, Тестирование веб-сервисов] История о PostgreSQL 13, Testcontainers и багах
- [Облачные вычисления, Разработка под e-commerce, Управление e-commerce, Облачные сервисы] Вебинар «Технологии, которые позволяют E-commerce опередить конкурентов» 6 апреля
- [Open source, Amazon Web Services, Распределённые системы] Apache Ignite в облаке AWS — базовый пример
- [Исследования и прогнозы в IT, Производство и разработка электроники, Финансы в IT] Кризис полупроводников оказался масштабнее, чем можно было ожидать
- [Информационная безопасность, Системное администрирование, DevOps, Kubernetes] 10 Kubernetes Security Context, которые необходимо понимать (перевод)
- [Nginx, Машинное обучение, DevOps, Микросервисы, Flask] Развертывание ML модели в Docker с использованием Flask (REST API) + масштабирование нагрузки через Nginx балансер
- [Ненормальное программирование, Программирование, Компиляторы, C] Один бинарник, любое окружение. Магия чистого C
- [Системное программирование, Nginx, Accessibility, Визуализация данных, DevOps] Парсинг логов при помощи Fluent-bit
- [Open source, Виртуализация, Разработка под Linux, Разработка на Raspberry Pi] Шпаргалка по Linux grep, домашний термостат на Raspberry Pi, эл. книга «Ansible for DevOps» и PostgreSQL на Linux
Теги для поиска: #_virtualizatsija (Виртуализация), #_devops, #_oblachnye_servisy (Облачные сервисы), #_paas, #_docker, #_aws, #_kontejnery (контейнеры), #_heroku, #_blog_kompanii_maklaud (
Блог компании Маклауд
), #_virtualizatsija (
Виртуализация
), #_devops, #_oblachnye_servisy (
Облачные сервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:20
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 При обсуждении создания нового проекта или разработке «дорожной карты» уже существующего варианты способов запуска рабочих нагрузок никогда не были столь обширными. Мы живём в эпоху, избалованную выбором платформ — можно выбирать между open-source-инструментами, платными сервисами, enterprise-продуктами и кучей всего ещё. Из-за этого принять решение о выборе стало сложнее — шансы получить «паралич выбора» растут с увеличением вариантов. В таких условиях справедливо будет задаться вопросом: по-прежнему ли контейнеры являются разумным выбором на текущий момент и на будущее, или мы уже их переросли? Чтобы ответить на этот вопрос, нужно рассмотреть альтернативы и сравнить их с контейнерами. Serverless Следующим логическим шагом после контейнеров являются serverless-решения. Такие сервисы, как AWS Lambda и Google Cloud Functions упрощают эксплуатацию serverless-приложений, особенно тех из них, которые по своей природе управляются событиями. Если учесть простоту работы с фреймворками приложений наподобие Serverless Framework, мы получаем простой рабочий процесс с учётом требований разработчиков, позволяющий перейти от идеи к продакшену за очень короткое время. Этот рабочий процесс может замечательно подойти для прототипирования API или быстрой разработки новых функций уже существующих продуктов. Одна из самых сильных сторон архитектуры serverless (особенно при запуске приложений у поставщика публичных облачных услуг наподобие AWS) заключается в том, что вы платите только за активно используемые вычислительные ресурсы; то есть за простой системы вы не платите. В перспективе это может обеспечить серьёзную экономию средств по сравнению с архитектурой «всегда включено», но только в определённых условиях. Существует порог, после которого стоимость выполнения приложения в serverless-среде становится выше, а производительность ниже по сравнению с таким же приложением, запущенным в выделенной ВМ, где вы платите не за вызов приложения, а почасовой тариф. Давайте сравним serverless с контейнерами: ПЛЮСЫ:
МИНУСЫ:
Platform-As-A-Service (PaaS) Похожи на serverless, но имеют свои уникальные особенности Platform-As-A-Service (PaaS) наподобие Heroku и CloudFoundry. Обычно PaaS отличаются от serverless тем, что предназначены для «постоянно работающих» сервисов, а не для управляемых событиями, однако похожи на них тем, что аналогично serverless обеспечивают удобные разработчикам рабочие процессы. Внутри большинство подобных решений на самом деле выполняет ваш код в контейнерах, но большая их часть абстрагирована от пользователя, поэтому зачастую они позиционируются как «buildpacks» — готовые контейнеры, обладающие определёнными особенностями или установленными в них языкозависимыми пакетами. Именно это абстрагирование и составляет удобство продуктов PaaS — все хлопотные аспекты выполнения приложения в продакшене абстрагируются от пользователя. Однако это может быть и одним из недостатков PaaS: могут возникнуть сложности с высвобождением приложений из платформ PaaS и перемещением их на другую платформу при необходимости. Кроме того, на некоторых не полностью сформировавшихся платформах нативная интеграция с внешними сервисами (базами данных, кэшами, очередями и т.п.) может быть ограниченной или отсутствовать вовсе, что значительно ограничивает варианты архитектуры. К тому же за абстрагирование и простоту использования приходится платить: платформы PaaS обычно дороже, чем такие IaaS в стиле «сделай сам», как AWS или GCP. ПЛЮСЫ:
МИНУСЫ:
Решения No-Code Решения No-code становятся популярнее как средство для быстрого развития стартапа, особенно среди не обладающих техническими знаниями организаторов. Возможность создания целой веб-платформы без необходимости изучать код привлекает, а для тех, кто не умеет кодить, она даже необходима. Современные решения no-code размывают границы пересечения бизнес-процессов и ПО; бизнес-логику, на разработку которой в прошлом могли тратиться недели, теперь можно создать за считанные минуты или часы на платформе no-code. Повторюсь, для не обладающих техническими знаниями людей или групп это может быть потрясающим успехом, но относится ли вообще такой подход к сфере разработки ПО? С точки зрения парадигмы решения no-code похожи на serverless тем, что обе концепции работают в модели управления на основе событий, однако решения no-code обладают одним серьёзным изъяном, которого нет у других платформ из нашего списка: чрезмерной привязкой к поставщику решения. На данный момент мне неизвестна ни одна платформа, позволяющая перенести приложение no-code с одной платформы на другую. Если вы решите писать своё базовое приложение в Microsoft Power Automate или Zoho Creator, то там вы и будете оставаться, пока не перепишете его на чём-то другом. ПЛЮСЫ:
МИНУСЫ:
Контейнеры Так где же место контейнеров среди всех этих технологий? Я склонен воспринимать контейнеры как фундаментальные строительные блоки архитектуры, как мельчайшие части приложения, которые не имеет смысла разделять. Вне зависимости от того, эксплуатируете ли вы внутри контейнеров микросервисы или целый монолит, контейнер должен представлять собой наименьший объём кода, который можно развернуть с сохранением его функциональности. На самом простейшем уровне контейнеры — это просто подмножество функций ядра. Такие функции, как изолирование ресурсов, сетевой тротлинг и т.п., являющиеся частью ОС Linux, преобразованы таким образом, чтобы людям было проще ими пользоваться. Вполне можно запустить процесс и управлять им с помощью cgroups, виртуальных сетей, iptables и прочих функций, имитирующих контейнер Docker, однако такие приложения, как Docker и Podman обеспечивают удобство пользования этими функциями, чтобы не приходилось делать всё это вручную. Именно это использование функций ядра обеспечивает контейнерам портируемость. При наличии машины под Linux с достаточно современным ядром вы без проблем сможете запустить практически любой контейнер. Однако за такую простоту нужно платить цену, и этой ценой является сложность эксплуатации. Для разворачивания продакшена недостаточно просто развернуть один контейнер на голой ВМ. Для «правильной» реализации вам понадобится некое управление контейнерами, повышающее сложность и эксплуатационные затраты. Однако несмотря на повышение сложности, контейнеры компенсируют его своей гибкостью и портируемостью. ПЛЮСЫ:
МИНУСЫ:
Заключение Хотя ваш личный выбор может сильно зависеть от приложений и нагрузок, я делаю очень простой вывод: контейнеры по-прежнему очень актуальны и так будет продолжаться очень долго. Несмотря на повышение сложности, их портируемость и уровень контроля позволяют инженерам делать именно то, что им нужно, без необходимости реверс-инжиниринга решения на основании чего-то типа Heroku. Используя наши облачные серверы вы сможете без проблем разворачивать свои контейнеры Docker. Это только одна из миллионов задач, которую можно воплотить вместе с Маклаудом! Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!  оригинал =========== Источник: habr.com =========== =========== Автор оригинала: Peter Christian Fraedrich ===========Похожие новости:
Блог компании Маклауд ), #_virtualizatsija ( Виртуализация ), #_devops, #_oblachnye_servisy ( Облачные сервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:20
Часовой пояс: UTC + 5