DevOps FM

Немного про Kubernetes (как вы могли догадаться :)
Точнее про автоскейлинг.

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

Механизмы автоскейлинга Kubernetes помогают автоматически масштабировать поды и ноды по мере необходимости. Есть три разных метода масштабирования:

• Horizontal Pod Autoscaler (HPA)
• Vertical Pod Autoscaler (VPA)
• Cluster Autoscaler (CA)

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

#статьи

В эфире — новости! ⚡️

▪️Релиз ядра Linux 6.5. Еще не успели отпраздновать день Рождения Линукса, а уже можно отмечать релиз. В этом выпуске представлена ​поддержка MIDI 2.0 в ALSA, поддержка ACPI для архитектуры RISC-V и поддержка Landlock для UML (User-Mode Linux). Подробнее о всех новых функциях можно прочитать здесь.

▪️Релиз Grafana 10.1. Полный обзор всех обновлений можно найти в документации Grafana, журнале изменений или в документации «Что нового».

▪️Веб-сервер Angie рассказал про сходства и различия между Angie и Nginx. Например, Angie ориентируется на платформы, для которых “официальный” Nginx будет собираться еще нескоро (ALT Linux, Astra Linux SE и РЕД ОС, а также процессоры “Байкал” и “Эльбрус”). На самом деле ноги у этой заметки растут из обсуждения в комментариях, интересно получилось.

▪️Релиз Git 2.42. Для знакомства с обновлениями (и, что самое приятное, можно почитать сравнения с предыдущими версиями) рекомендуем эту заметку. А еще внутри много полезных ссылок.

Если мы пропустили что-то важное, обязательно дополняйте в комментариях :)

Всем DevOps и классной недели! 🔥

#новости

Happy Birthday, Linux! 💻

Про эту дату мы не могли забыть :) Вообще с днем Рождения Linux история неоднозначная, есть как минимум 4 возможные даты:

🗓 3 июля. В этот день Линус Торвальдс впервые упомянул о разработке новой ОС и попросил нужные спецификации POSIX в ньюс-группе Minix.

🗓 25 августа. В этот день было опубликовано письмо в ньюс-группе Minix с официальным анонсом проекта. Это наиболее подходящая дата, потому что есть официальный документ с датой, временем и т.д., считает Линус Торвальдс.

🗓 17 сентября. В этот день был выпущен релиз 0.01.

🗓 5 октября. День первого истинно публичного релиза, когда вышла версия 0.02 (+1 патч).

В честь праздника от души рекомендуем несколько классных материалов про Linux:

⚙️ Документальный фильм «Revolution OS» — про историю GNU, Linux, а также open source и free software-движения. Ссылка ведет на русскую озвучку, начинайте с 6:35, до этого момента автор озвучки рассказывает про себя.

⚙️ Видео «The mind behind Linux | Linus Torvalds» (en | en sub / ru sub) — 7 лет назад Линус Торвальдс дал небольшое интервью на TED и рассказал о своем видении технологий, философии open-source и немного о себе.

⚙️ Статья «Собираем и запускаем Linux-0.01 в Minix 1.5, (почти) как это делал Линус Торвальдс» — автор попытался повторить, насколько это возможно, действия Линуса Торвальдса по компиляции и запуску самой первой версии ядра Linux 0.01.

Live long and prosper, Linux! 🎉

Всем пятница и хороших выходных! 🖖

#новости #статьи #видео

Немного про Mobile DevOps ♾

Кто-то считает, что Mobile DevOps'а — нет, есть только DevOps практики и методология, а где они используются — роли не играет. Но нам кажется, что своя специфика у Mobile DevOps есть.

Рекомендуем познакомиться с материалами по этой теме и сделать свои выводы. А еще лучше — поделиться мыслями в комментариях :)

Начать можно с двух статей:

⚙️ «Да кто такой этот ваш Mobile DevOps?» — интересный рассказ про типичные проблемы мобильных команд (да-да, вы можете узнать в них свои), а также что такое Mobile DevOps и как получить этот самый Mobile DevOps к вам в команду.

⚙️ «Зачем разработчикам приложений нужен Mobile DevOps?» — а в этой статье рассказывается про то, какие проблемы решает Mobile DevOps, почему он может принести большую пользу компаниям, стремящимся к полной интеграции IT и других операционных взаимодействий с их бизнес-целями.

▪️ После знакомства с общими статьями, можно углубиться в детали. Для этого отлично подойдет серия статей — как GitLab можно использовать для Mobile DevOps (часть 1, часть 2, часть 3)

▶️ А потом — посмотреть видео «Особенности SRE и Observability в мобильных приложениях». Так уж сложилось, что тема SRE получила наибольшее распространение именно в серверных средах — бэкенды, апишки, базы. Однако с ростом количества мобильных телефонов и увеличением их роли в жизни людей вопросы доступности, наблюдаемости и надёжности мобильных приложений стали вставать всё острее.

Что думаете про Mobile DevOps? ❓

#статьи #видео

Всем DevOps! 🖖

Вышло продолжение серии статей от Datadog про безопасность контейнеров: Container security fundamentals part 5: AppArmor and SELinux.

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

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

Предыдущие части серии можно найти здесь. Про SELinux тоже писали :)

#статьи

Классный open-source инструмент — Docker Bench 💻

Это скрипт, который проверяет десятки распространенных best practices развертывания контейнеров Docker в продакшене. Все тесты автоматизированы и основаны на CIS Docker Benchmark v1.5.0.

Для работы Docker Bench требуется Docker 1.13.0 или более поздние версии.

Лицензия Apache-2.0, 8.5k звездочек на GitHub 🌟

#open_source

В эфире — новости! ⚡️

▪️ Мировой рынок облаков за год вырос на $10 млрд — затраты на облачные ресурсы во II четверти 2023-го составили приблизительно $65 млрд. Это на $10 млрд больше по сравнению с аналогичным периодом предыдущего года. Таким образом, зафиксирован третий квартал подряд, когда рынок облачных вычислений вырос на $10 млрд в годовом исчислении.

▪️ Анонсирована стабильная версия Ceph Reef 18.2.0 — из важного: по состоянию на 07.08.23 невозможен билд Ceph этой версии на Debian GNU / Linux 12.0 (Bookworm) из-за ошибки на стороне Debian. С тех пор апдейтов не было.

▪️ C 16 августа 2023 г. GitLab будет требовать от пользователей, которые не используют двухфакторную аутентификацию ( 2FA ), подтвердить действительный адрес электронной почты при входе в систему.

▪️GitLab Container Registry теперь поддерживает артефакты Falcoctl OCI. Точнее это обновление войдет в релиз GitLab 16.3. Falcoctl — одна из новейших разработок сообщества Falco. Это инструмент командной строки, который позволяет управлять полным жизненным циклом правил и плагинов Falco, используя возможности OCI Artifacts.

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

А еще Kubernetes представили репозитории, принадлежащие сообществу Kubernetes, для пакетов Debian и RPM: pkgs.k8s.io. Новые репозитории пакетов заменяют репозитории пакетов, размещенные в Google ( apt.kubernetes.io и yum.kubernetes.io), которые использовались, начиная с версии Kubernetes 1.5.

Что-то забыли? Дополняйте в комментариях :)

Всем DevOps и отличной недели! 🖖

#новости

Не любите Docker? Вы просто не умеете его готовить! 🤣

С Docker Cookbook есть шанс научиться. Ладно, если серьезно, эту отличную книгу нам порекомендовал подписчик, большое спасибо :) Разумеется, делимся!

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

Как раз можно на выходных почитать (хотя, конечно, на выходных лучше отдыхать 🏖)

Всем пятница и хороших выходных! 🔥

P.S. Если вы знаете какой-то классный материал, инструмент, увидели интересную новость и т.д. и хотите поделиться ими с сообществом — пишите!

#книги

Что нового по части безопасности добавилось в Kubernetes 1.28

Отличная статья от Рори МакКьюна, специалиста по безопасности, контейнеризации (Kubernetes/Docker), облачным вычислениям и т.д. из DataDog.

В статье рассматривается два изменения:

⚙️ Бета-версия Validating Admission Policy — функция, впервые представленная в Kubernetes 1.26, достигла статуса бета-версии в версии 1.28. Предоставляет встроенный механизм для проверки рабочих нагрузок при входе в кластеры Kubernetes. Ранее единственным вариантом реализации контроля доступа без использования сторонних продуктов был Pod Security Admission, которому не хватало гибкости, необходимой для более сложных сред.

⚙️ Stable-версия SelfSubjectReview API — эта функция была выпущена в бета-версии Kubernetes 1.27, и она позволяет пользователям идентифицировать атрибуты о себе. В Kubernetes нет базы данных пользователей, поэтому пользователям традиционно было трудно понять, как их видит кластер, и узнать подробную информацию о себе, например, о членстве в группах. Эта функция обеспечивает простой способ получения этой информации с сервера API.

P.S. У Рори МакКьюна есть и отдельный блог, писали про него здесь.

#статьи

Вчера Debian исполнилось 30 лет, а мы ничего не написали! Непорядок, исправляемся 😁

Итак, 30 лет назад Ян Мердок написал в группу новостей comp.os.linux.development о завершении совершенно нового выпуска Linux. Вот здесь вы тоже можете прочитать эту новость, прикоснуться к истории, так сказать.

В дополнение рекомендуем видео «Early History of Debian» от Бдейла Гарби, разработчика, который принимал участие в создании Debian с первых дней проекта.

Сегодня Debian используют в кластерных системах, ЦОДах, ПК, IoT-устройствах, ноутбуках, серверах и даже в космосе :)

Live long and prosper, Debian! 🎉

#новости

Всё собрали в одну подборку — удобнее сохранять :)

Как выбрать оптимальную архитектуру для вашего Kubernetes-кластера?

⚙️ Часть 1 — иметь множество маленьких нод или несколько больших — это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?

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

⚙️ Часть 2 — конкретные вопросы, на которые нужно ответить, чтобы определиться с архитектурой и факторы, которые нужно учесть.

⚙️ Часть 3 — что нужно сделать, чтобы найти оптимальные значения? Посчитать! (пример расчетов)

#статьи

Подводя итог

Учитывая все вышесказанное, вам нужно сделать следующее, чтобы найти оптимальные значения:

Количество контейнеров на ноде = Корень квадратный из количества контейнеров, округленный до целого в меньшую сторону, при условии, что количество контейнеров на ноду не превышает рекомендуемое значение

Количество нод = Количество контейнеров/Количество контейнеров на ноду

Запас ресурсов = Количество контейнеров на ноду * Максимальное количество ресурсов на контейнер/(Количество нод - Максимальное допустимое количество отключенных нод)

Ресурсы ноды = максимальное кол-во ресурсов, требуемое контейнеру * кол-во контейнеров на ноде + запас ресурсов + ресурсные требования системных компонент Kubernetes

Чтобы понять, как это работает, давайте рассмотрим пример.

Давайте скажем, что нам нужны два пула нод:

Микросервисы - 200 микросервисов с 0.1 CPU и 100MB RAM, требуемых на контейнер.

Базы данных - 20 PostgreSQL баз данных с 2 CPU и 4GB RAM, требуемых на контейнер.

Предположим, что компоненты Kube system будут потреблять 0.5 CPU и 0.5 GB RAM и мы рассчитываем, что только одна нода может быть недоступна за раз.

Для микросервисного пула:

Ближайшее меньший целый квадрат числа = 196

Кол-во контейнеров на ноду = sqrt(196) = 14

Кол-во нод = 200/14 = 14.28 ~ 15

Максимальное допустимое число неработающих нод = 1

Запас ресурсов = 14 * (0.1 core + 100MB RAM)/(15–1) = 0.1 core + 100MB RAM

Ресурсы ноды = (0.1 core + 100MB RAM) * 14 + 0.1 core + 100MB RAM + 0.5 cores + 500MB RAM = 2 core + 2GB RAM

Для пула баз данных:

Ближайшее меньший целый квадрат числа = 16

Кол-во контейнеров на ноду = sqrt(16) = 4

Кол-во нод = 20/4 = 5

Максимальное допустимое число неработающих нод = 1

Запас ресурсов = 4 * (2 core + 4GB RAM)/(5–1) = 2 core + 4GB RAM

Ресурсы ноды = (two core + 4GB RAM) * 4 + 2 core + 4GB RAM + 0.5 cores + 0.5 GB RAM = 10.5 core + 20.5 GB RAM

Следовательно, для микросервисного пула вам будет нужно 15 воркер нод с 2 ядрами и 2 GB RAM каждая, и для пула БД вам нужно будет 5 воркер нод с 10.5 ядрами и 20.5 GB RAM каждая. Для простоты можно округлить числа до ближайшей большей доступной конфигурации машины.

*️⃣3/3

#лонгрид

Выбор размера нод

Что ж, выбор зависит от множества факторов, как всегда! Истина где-то посередине и не стоит выбирать ни одну из крайностей.

Вам нужно ответить на вопросы ниже, чтобы найти свой оптимальный размер.

Какой тип приложений вы запускаете?

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

Можно ли объединить приложения в группы?

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

Максимальное количество ресурсов для каждой категории

Если вы можете сгруппировать приложения по категориям, то после этого вам нужно понять сколько максимум ресурсов может потребоваться на одно приложение из каждой категории. Например, если вы запускаете микросервисы, монолиты и БД в кластере, вам нужно взять максимальные затраты на один инстанс БД, микросервис или монолит.

Посчитать количество приложений в каждой категории

Следующий шаг это найти планируемое количество приложений в каждой из категорий. У вас может быть, например, 8 БД MySQL, 200 микросервисов и 9 монолитов. Запишите их. Не перебарщивайте. Kubernetes спроектирован для масштабирования и вы всегда можете использовать автоматическое масштабирование кластера у некоторых провайдеров. Либо, вы можете добавить ноду вручную позже.

Поместите каждую категорию в отдельный пул нод

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

Заложите отказоустойчивость

Нужно иметь минимум две ноды в каждом пуле для достижения отказоустойчивости. Kubernetes рекомендует максимум 110 контейнеров на ноду. Так же есть ещё системные контейнеры, которые запущены на нодах, так что имейте это ввиду.

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

Подгоните свои ноды под контейнеры для оптимального управления ресурсами

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

Подгоните ваши контейнеры и ноды для лучшего возможного управления ресурсами. Например, если у нас есть 20 контейнеров, лучше всего будет распределить по 4 пода на одну ноду, тогда нам нужно иметь в запасе 20% ресурсов на каждой ноде, вместо 100% как если бы у нас было всего 2 ноды.

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

Учтите нагрузку от самого Kubernetes

Учтите тот факт, что системные компоненты Kubernetes так же будут потреблять какое-то количество CPU и памяти на каждой ноде, поэтому на самом деле вам будет доступно меньше ресурсов, чем есть на ноде. Уточните эти параметры у вашего облачного провайдера и добавьте к ресурсам ноды.

*️⃣2/3: продолжение следует :)

#лонгрид

Всем DevOps! 🖖

Сегодня хочется рассказать что-нибудь полезное. Решили поделиться советами. Потом по традиции соберем в один пост, чтобы сохранять было удобнее :) Погнали!

Как выбрать оптимальную архитектуру для вашего Kubernetes-кластера?

Вопрос, конечно, интересный. Управление Kubernetes-кластером — это не та задача, где есть одно правильное решение на все случаи жизни. Есть много способов оптимизации кластера и главное здесь — это обеспечение стабильной и отказоустойчивой работы приложений.

Выбор правильного размера ноды критичен для разработки масштабируемых приложений. Иметь множество маленьких нод или несколько больших — это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?

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

Отказоустойчивость

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

Если у нас есть две больших воркер ноды и одна их них упадет, то мы потеряем половину всех ресурсов кластера. Если вы не предусмотрели 100% запас ресурсов, то это приведет к катастрофе, так как оставшаяся нода не сможет выдержать двойную нагрузку. Наличие множества воркеров снижает эти риски на n. К примеру, если у вас есть 10 нод в кластере и выключится одна, то вы потеряете только 10% от всей мощности кластера.

Победители: множество маленьких нод 🎉

Сложность управления

С большим количеством нод вам нужно будет заботиться о большем количестве серверов, их обновлении и обслуживании. Сократив количество нод их проще обслуживать. Как DevOps и SRE вы можете использовать такие инструменты как Ansible или Puppet, чтобы упростить эти процессы за счет автоматизации.

Если вы используйте managed Kubernetes-кластер, то ваш облачный провайдер будет патчить и обновлять ноды за вас. В итоге с современными инструментами этот пункт не дает существенного преимущества.

Победители: нет 🎉

Простота в распределении контейнеров

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

Победители: несколько больших нод 🎉

Нагрузка на kubelet

Kubelet отвечает за взаимодействие с нижележащим container runtime (движком для контейнеров) для запуска приложений на воркер нодах. Если вы запускаете множество контейнеров на одной ноде, что типично для кластеров с большими нодами, это может перегрузить kubelet, так как ему нужно будет оперировать большим количеством контейнеров.

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

Победители: множество маленьких нод 🎉

Нагрузка на систему

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

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

Победители: несколько больших нод 🎉

*️⃣1/3: продолжение следует :)

#лонгрид

На сегодня, 15.08.2023, назначен релиз Kubernetes 1.28 🎉

Для знакомства с улучшениями рекомендуем классную статью из блога с забавным названием Ku🍺netes.

Всего запланировано 44 изменения, из которых 19 Alpha, 14 Beta и 11 Stable.

#новости

Всем DevOps! 🖖

Продолжаем наблюдать за реакцией сообщества на заявление HashiCorp. Вот, например, на Hacker News рассуждают о плюсах и минусах смены лицензии. Там же поделились репозиторием Open-Terraform.

Open-Terraform — это форк Terraform от Hashicorp с открытым исходным кодом, который сохраняет лицензию MPL после объявления Hashicorp об изменении лицензии на BSL. В общем, будем наблюдать.

Кроме Terraform лицензию изменили у всех основных продуктов компании (Vault, Vagrant, Consul, Nomad, Packer, Boundary).

Затронуло ли вас изменение лицензии HashiСorp? Планируете переходить на альтернативы?

#новости #open_source

👋 Друзья, коллеги, господа!
У нас накипело!

⌨️ Полгода назад взломали сервера нашего крупного клиента. Причина — «дыра» в выделенных серверах в ЦОДе провайдера. Перевезли к себе и защитили.

🔴 Месяц назад упала инфраструктура у другого клиента...
... и снова на выделенных серверах у крупного провайдера.

📍 Неделю назад «умерли» сервера ещё у трёх — тоже перевезли к себе.

📌 При этом цены на «дедики» летят в космос, техподдержка не радует вовлечённостью, а клиенты и партнёры сетуют на качество.

Выделенные сервера — не наш бизнес. Мы — сервис-провайдер и занимаемся облаками, но пул клиентов растёт, и вам нравится то, что мы делаем.

Поэтому мы создаём новый сервис по аренде выделенных серверов:
💸 с адекватными ценами;
🤝 качественной техподдержкой;
✅ клиентом на первом месте.

Мы хотим учесть пожелания каждого, поэтому проводим короткий опрос на 3 минуты. Пожалуйста, поделитесь своим мнением, вы очень поможете.

❗️Все новости и обновления нового сервиса будут в этой группе.

Присоединяйтесь, если вы ждали Hetzner по-русски.

HashiCorp меняет лицензию на исходный код

Компания сообщила, что переходит с Mozilla Public License v2.0 (MPL 2.0) на лицензию Business Source (BSL, также известную как BUSL) v1.1 для всех будущих выпусков продуктов HashiCorp. API-интерфейсы HashiCorp, SDK и почти все другие библиотеки останутся MPL 2.0.

Подробнее про лицензию BSL можно узнать здесь.

#новости

Всем DevOps! 🖖

В одной из рассылок (старый добрый email 🥰) была поднята интересная тема.

Итак, полторы недели назад инженер по машинному обучению написал анализ под названием «Падение Stack Overflow». Из собранных им данных и из данных, которыми делится StackOverflow с самой активной частью комьюнити, следует, что Stack Overflow потерял около 50% своего трафика. Впрочем оказалось, что данные о трафике не учитывают изменения в Google Analytics. С учетом этого падение составило бы 35%. Тем не менее, самая тревожная часть статистики — это не трафик, а снижение количества задаваемых вопросов и ответов.

Кажется, что падение Stack Overflow (и прочих подобных сайтов) связано с активным развитием AI-инструментов для написания кода (ChatGPT, Copilot и т.д.) — пользователи все больше отдают им предпочтение.

Автор рассылки связался со Stack Overflow, чтобы получить официальный комментарий и разобраться в ситуации.

В общем, можете посмотреть это письмо в Telegraph, ну и поделиться своим мнением в комментариях :)

Пользуетесь ли вы AI-инструментами для работы с кодом? Или просто для рабочих задач? А Stack Overflow — пользуетесь?

#статьи

Failover & Fallback

Похожие термины, но важно понимать различие :) То, что вы думаете, может не совпадать с тем, что вы говорите, то, что вы говорите, может не совпадать с тем, что слышится, а то, что слышится, может не совпадать с тем, что реализуется!

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

❓Failover — переключение с основной системы на запасную, если первая вышла из строя или недоступна.

❓Fallback — возврат к предыдущему состоянию или конфигурации, если изменение или обновление вызвало проблемы.

#статьи