Hi all!

We recently introduced Drim Seminars as a new activity in the Drim Team. Seminars are designed to allow participants to discuss important programming and system design topics together. The goal is to expand everyone's knowledge and experience.

We conducted the first seminar yesterday. The topic was "idempotency," a vital concept programmers must understand to develop correct software systems. The participants elaborated on this idea, learning the following things in the process:

* Which HTTP requests must be idempotent and which are not;
* How to deduplicate non-idempotent requests on both client-side and server-side;
* How Stripe API supports idempotency;
* How Microsoft Azure API supports idempotency;
* What is the OASIS Repeatable Requests standard;
* What is the difference between PUT and PATCH requests;
* What is JSON PATCH, and how it affects idempotency;
* Which processing guarantees Apache Kafka supports;
* Why idempotent consumers are essential for some processing guarantees in Apache Kafka;

We published the seminar on YouTube with information sources (articles and books) listed in the denoscription: https://youtu.be/3M5b-EY66yM?feature=shared

The video is in Russian language.

Seminars proved to be an effective learning format, so we will conduct them regularly. Keep in touch!

Do you want to become a more proficient developer?
Do you want to improve your software architecture skills?
Do you want to make better software design decisions?
Do you want to build software faster and with greater quality?

Use architectural decision records.

What is it? An architectural decision record is a document that captures a significant architectural decision made during software system development. It records the reasoning behind the decision, the context in which it was made, and any alternatives that were considered.

The primary purpose of an ADR is two-fold. First, it gives the team a concrete process for making architectural decisions. Second, it aims to provide future developers, architects, and stakeholders with the historical context of why the team chose a particular approach.

Let's look at an example. Suppose you are developing a microservices application and decide to use gRPC as a communication method. You create a diagram depicting the microservices and arrows between them labeled "gRPC." With this approach, you document what design decision you've made. But you don't document why you've made this decision. Is it necessary to elaborate on the "why" side? Yes, it is. Here are the reasons:

1. The formal process of decision documenting forces the team members to think more thoroughly about possible design options and their trade-offs, thus reducing the number of poor choices.
2. Team members can review decisions using pull requests, allowing them to do so asynchronously and more thoughtfully.
3. If a team member has any questions about implementing a feature, ADRs are a good place to consult and learn how to do it.
4. Evolving the system design and architecture will be easier based on the decision history.
5. New team members can read through all ADRs and quickly gain a broad understanding of the system design and implementation, thus reducing onboarding time.
6. Writing ADRs is an excellent exercise for improving software design skills.

Returning to the gRPC example, you can see what an ADR regarding this decision can look like. It is an ADR from the Drimstarter project (we'll talk about this project later) https://github.com/drim-dev/drimstarter/blob/develop/documents/adrs/backend/0001-grpc-communication.md.

I described the basic idea of ADRs and hope you will consider using them on your projects. In future posts, we will discuss specific details and formats. Before that, you can consult a couple of excellent resources on ADRs:

* https://adr.github.io/
* https://github.com/joelparkerhenderson/architecture-decision-record

I will be glad to hear your questions and feedback in the comments.

Join the online meeting where we will discuss architectural decision records.

https://www.meetup.com/drim-events/events/303461315/

A video recording of the ADR seminar can be found at https://youtu.be/iOuRxI0dbPo

My friend Askhat Omarov is looking for a tech lead for his product https://farel.io. I can recommend Askhat as a competent manager who has created a team of senior and lead level specialists. Contact me @mitro52 if you are interested. Here is the position denoscription:

Farel is a San Francisco-based startup revolutionizing how airlines manage inventory and sales with our cutting-edge SaaS platform. We’ve raised over $4M from top-tier Silicon Valley investors, including Y Combinator (the launchpad for companies like Airbnb, Dropbox, and Coinbase). Our previous team successfully built an online travel agency (OTA) that was acquired by a publicly-traded company. With a diverse and dynamic global team across the US, Georgia, Turkiye, Kazakhstan, Brazil, and Mexico, we are ambitiously pushing the boundaries of the aviation industry.

We are looking for a Tech Lead to join our growing team and help bridge the gap between business requirements and technical execution. In this role, you will ensure that our system architecture is cohesive, scalable, and aligned with business objectives. You will take ownership of the technical vision, work closely with business and engineering teams and provide leadership in making key decisions.

Key Responsibilities:

• Design, review, and approve architectural solutions for new and existing features, ensuring seamless integration and scalability across the platform

• Act as a bridge between product managers and developers, ensuring business requirements are effectively translated into technical implementations

• Lead discussions on technical challenges and solutions, providing clear guidance to the development team, and making authoritative technical decisions

• Collaborate with product managers and developers to define technical project roadmaps, aligning them with business goals and ensuring efficient resource utilization

• Establish and promote software engineering best practices for code quality, security, and system performance, with a focus on sustainable long-term architecture

• Provide technical guidance and mentorship to backend and frontend developers, helping them grow their skills and ensure alignment with the overall architecture

• Maintain a high-level view of the project, identifying potential bottlenecks and areas for improvement, and ensure that all technical decisions contribute to the broader business strategy

Qualifications:

• 6+ years of experience in software architecture, solution design, or technical leadership roles

• Deep technical knowledge of Spring, Spring Boot, PostgreSQL, Angular, Azure, Kubernetes, and GitLab. Proven experience translating business requirements into robust technical solutions

• Strong communication and interpersonal skills, with the ability to influence both technical and non-technical stakeholders

• A passion for solving technical challenges while understanding the broader business context.

Additional Skills:

• Experience working with cross-functional teams in a startup environment.

• Ability to make high-stakes decisions and take responsibility for their outcomes.

• Understanding of BPMN and workflow design, a plus.

If you are interested but don't know if you have the necessary skills, I can assess them by calling and talking to you.

Я решил изменить язык канала с английского на русский. Причина в том, что на текущем этапе развитие Drim будет сфокусировано на рынке СНГ. Русский язык позволит расширить аудиторию канала и сделать его более полезным.

Вчера я запустил лендинг Drim - https://drim.dev/

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

18 декабря в 20:00 по времени Астаны Дмитрий Мельник проведёт публичный семинар на тему "Использование платёжного шлюза Stripe для приёма онлайн-платежей".

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

После этого мы посмотрим, как организовать на сайте приём платежей за товары и услуги с помощью популярного сервиса Stripe. Бекенд демонстрационного приложения будет создан с помощью ASP.NET Core 9, а фронтенд - с помощью React и Next.js.

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

Приходите, будет интересно и полезно!

Ссылка на событие - https://www.meetup.com/drim-events/events/304858560.

Вступайте в группу https://www.meetup.com/drim-events, чтобы не пропустить это событие и узнавать о новых 🚀

Ссылка на Google Meet - meet.google.com/uay-qcfe-fgs

Больше информации о Drim можно получить на сайте https://drim.dev/.

Напоминаем, что сегодня в 20:00 по времени Астаны Дмитрий Мельник проведёт открытую онлайн-лекцию на тему "Введение в финтех на примере поставщика платёжных услуг Stripe" (тема немного изменилась с момента прошлого анонса).

Это первая лекция из планируемого цикла открытых лекций про финтех. После прохождения цикла участники смогут хорошо ориентироваться в том, как устроен финтех. Это индустрия, которая по прогнозам вырастет до 700 миллиардов долларов к 2030 году. Сейчас объем рынка составляет 200 миллиардов долларов. То есть прогнозируется рост в 3 раза. Это создаёт много возможностей как для предпринимателей, так и для разработчиков в этой сфере - можно построить успешную карьеру 💰.

Подписывайтесь на канал @drim_channel, чтобы узнавать о следующих лекциях.

Ссылка на Google Meet, где будет проведена сегодняшняя лекция - meet.google.com/uay-qcfe-fgs

Приходите на лекцию и начните свой путь в мире финтеха 🚀

Опубликовали на YouTube запись вчерашней лекции про финтех - https://youtu.be/bKJ-bzcTm7U?si=IR2Z09Wytzv6Vahv.

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

После лекции участники высоко оценили качество и ценность материала, поэтому всем рекомендую к просмотру ☀️.

Поздравляем всех с новым 2025 годом! ☀️

Желаем крепкого здоровья, много энергии и баланса между личной жизнью и работой! Уверенно идите по дороге, которая ведёт к процветанию и профессиональному успеху!

Нам с вами по пути! 🚀

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

Цель моей активности - выведение индустрии ИТ в Казахстане на новый уровень. Чтобы у нас делали крутые вещи, активно участвовали в опен-сорсе, были крутые известные специалисты. За пример можно индустрию Украины взять, где делают много классных продуктов и много классных профессионалов.

Понятно, что это звучит масштабно и амбициозно, но чем больше цель, тем больше можно сделать на пути к ней)

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

Вот такую точку притяжения я создаю - сообщество Drim Team.

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

Месяц назад ко мне пришёл участник сообщества за советом по поводу централизованного логгирования. У них в компании используется прямая запись логов из сервисов в Elasticsearch. Он же хотел рассмотреть и предложить руководству другую схему - использование OpenTelemetry Collector (эту схему мы детально изучали на одном из моих курсов). С этой идеей он обратился ко мне, чтобы обсудить плюсы и минусы.

Главная проблема текущего решения заключалась в производительности. Под большой нагрузкой им иногда приходилось отключать логгирование, чтобы снизить нагрузку на сервера. Это сильно снижало потребление процессора и памяти. Но кто даст гарантию, что схема с OpenTelemetry Collector будет более производительной? Единственный способ это узнать - провести нагрузочное тестирование обоих подходов и сравнить потребление ресурсов. Это мы и решили делать.

В итоге родился вот этот проект https://github.com/drim-dev/logging-benchmarks.

Там мы нагружаем систему с прямым логгированием в Elasticsearch, потом с OpenTelemetry Collector, потом без логгирования, и сравниваем метрики. Реальные результаты уже есть, скоро их опубликуем.

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

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

Первая идея - создание оператора Kubernetes для того, чтобы он автоматически создавал сервера, разворачивал инфраструктуру для нагрузочного тестирования, проводил нагрузку, собирал результаты и удалял сервера. Тогда эксперименты по сравнению разных технологий можно будет описывать в виде Custom Resource Definition. Это один YAML-файл, который можно быстро изучить и понять, что с чем сравнивалось. Плюс каждый сможет воспроизводить полученные результаты и проводить свои собственные эксперименты. Такого инструмента я нигде не видел, и он может стать востребованным на мировом уровне, делая специалистов из Казахстана более известными.

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

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

Пишите, если вам интересно. И подписывайтесь на канал, чтобы быть в курсе ☀️

В предыдущем посте я обещал опубликовать результаты сравнения двух популярных подходов к централизованному логированию:

1. Прямая запись логов приложением в Elasticsearch

2. Запись приложением логов в файл с последующим чтением и отправкой в Elasticsearch с помощью OpenTelemetry Collector

Результаты готовы и оформлены.

Но вначале пара слов о том, как родился этот проект. В сообществе Drim Team мы сообща изучаем новые технологии и помогаем друг другу с разными задачами. В начале декабря ко мне пришёл участник сообщества Сергей Рубцов (https://news.1rj.ru/str/sergey_rubtsov) за советом по поводу централизованного логирования. На работе у них используется схема с прямой записью в ES, он же хотел предложить руководству использовать вариант с OpenTelemetry Collector.

В процессе обсуждения мы поняли, что у нас не было информации, какое из этих решений работает быстрее. Решили провести нагрузочное тестирование и узнать это. Кроме того, решили замерить потребление ресурсов с отключенным логированием, чтобы понять, насколько его использование увеличивает нагрузку на систему. Так родился этот репозиторий https://github.com/drim-dev/logging-benchmarks.

В README репозитория описаны результаты сравнения https://github.com/drim-dev/logging-benchmarks/blob/main/README.md. Почитайте - там интересные цифры. Приведу здесь основные выводы на русском:

1. Логирование вносит значительную дополнительную нагрузку. Обе схемы логирования (напрямую в Elasticsearch и через OTel Collector) повышают загрузку процессора с 32% до примерно 50–55%. Потребление CPU возрастает на 65–75%, что очень значительно. Потребление оперативной памяти также сильно возрастает.

2. OTel Collector обеспечивает лучшую производительность по сравнению с прямой отправкой в Elasticsearch. Несмотря на немного более высокую загрузку процессора (55% по сравнению с 52%), решение на базе OTel Collector демонстрирует самые низкие значения летенси (средней, медианной и 90-95 перцентилей). При этом потребление памяти значительно ниже (8,5% по сравнению с 12%). Похоже, что такая конфигурация снимает часть нагрузки с процесса приложения, делая летенси более стабильной и предсказуемой.

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

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

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

Если вам интересно узнать больше о сообществе Drim Team, информацию вы можете найти на сайте https://drim.dev

P.S. Буду признателен, если вы поставите звёздочку проекту на GitHub 🙂

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

Мы провели первый звонок, где обсудили, как можно реализовать оператор на языке Go с помощью Operator SDK https://sdk.operatorframework.io/

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

https://youtu.be/2U0xRhKK9A0

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

Вот отзыв:

Прошло полтора года с тех пор, как я начал проходить курсы и присоединился к сообществу Drim Team. Тогда я озвучил цель «снова начать писать на C#» и «понять, как сейчас пишут современные приложения на C# и .NET». Для себя хочу отметить, что обе цели были достигнуты и перевыполнены благодаря всем тем лекциям, что провел Дмитрий Мельник. Активности на курсах и в сообществе вернули мне интерес к учёбе и развитию.

И самое главное - знания, полученные в Drim, помогли мне получить должность техлида в команде разработчиков C#!

Дархан Изтлеу, техлид в "Банк ЦентрКредит"

От стэнфордского преподавателя Lakshya Jain. Я преподаю базы данных в Беркли в этом семестре. Мои студенты кажутся необычайно блестящими. Немногие приходят за консультациями на office hours, и не так много людей задают вопросы по проекту на форуме курса. Странно, но на экзамене был самый низкий средний балл за 10 семестров, что я его преподаю. Другими словами, я почти уверен, что многие студенты информатики используют ChatGPT для выполнения своих заданий по программированию вместо того, чтобы делать их самостоятельно. Если это правда, то это огромная проблема. Процесс обучения отладке имеет решающее значение для роста как инженера. По моему мнению, следствием этого может стать то, что курсы должны будут давать еще меньше поддержки, чтобы студенты не могли полностью выполнить задание с помощью GPT. Дизайн проектов также может стать еще более важным. Теория также станет еще более важным фильтром для оценки компетентности.

Вот проблема использования GPT в качестве студента. В производственных системах вы столкнетесь с вещами, где ЭТО НЕ РАБОТАЕТ. Вы не можете просто использовать GPT как костыль, отчасти потому, что у вас даже не будет контекста, необходимого для составления запроса для решения проблемы. Например, бывают случаи, когда код настолько запутан, а ошибка настолько невероятно сложна для отладки, что вы не сможете пробиться через нее с помощью GPT. Единственный способ исправить это — установить точку останова, войти в отладчик и посмотреть, какие значения у определенных переменных. При настройке кодовой базы бывают случаи, когда GPT терпит неудачу. Здорово использовать GPT в качестве помощника — я использую его постоянно. Вы не можете использовать его в качестве основного средства разработки, потому что вы функционально не понимаете, что делаете (кроме копирования и вставки).

Теперь вы можете спросить что, если мои задачи на работе достаточно просты, чтобы GPT все легко решал? Разве я не могу просто использовать его для этого? Поздравляю. Возможно, вы открыли путь к безработице. Если ИИ делает все, что вы можете делать, зачем им вас держать? Для набора навыков в области информатики, который нельзя просто заменить ИИ, вам нужно изучить основы. Это позволит вам выполнять задачи, которые ИИ до сих пор не может, потому что ваш мозг очень мощный. Если вы прокладываете себе путь с помощью ChatGPT, вы не строите никаких связей для дальнейшего использования. Переведно через Gemini AI. Автор промпта А. Айтуов- @devs_kz

В интересном треде преподаватель из Стэнфорда поднимает важную проблему - https://x.com/lxeagle17/status/1899979401460371758 Массовое использование больших языковых моделей (LLMs) приводит к тому, что существующие методики обучения перестают работать. Мы не можем запретить использование LLM, поэтому нужно встраивать их в процесс. Сейчас опишу свой опыт в этом.

Недавно я начал обучение GameDev-разработчика, который хочет переквалифицироваться в DevOps. С самого начала мы решили, что для обучения будем активно использовать ChatGPT. Это решение было основано на двух гипотезах:

1. ChatGPT позволит значительно сократить время обучения
2. Нужно сразу учиться решать задачи с использованием ChatGPT. Ведь в реальной работе это так и будет происходить

В итоге я сформировал следующую методику:

Обучение происходит путём выполнения конкретных приближенных к реальности задач. Есть выдуманный стартап под названием AI Tutor. Он разрабатывает бота-преподавателя. Студент работает в нём в качестве DevOps. По мере роста стартапа появляются всё новые задачи, которые нужно выполнять.

Примеры задач:

1. Нужно запустить лендинг стартапа. Для этого нужно на виртуалке AWS запустить nginx и захостить там простой лендинг. После чего купить и привязать домен. На виртуалке нужно организовать SSH-доступ для разработчика. Разработчик должен иметь права только на модификацию лендинга.

2. Прошли первые питчи, пошли первые посетители, стартапу теперь нужен блог. Нужно развернуть блог с использованием ghost и настроить роутинг в nginx, чтобы он был доступен по пути /blog на сайте лендинга. Кроме того, давайте сразу настроим отказоустойчивость. Ожидается посещение сайта серьезными партнёрами, поэтому он должен быть доступен всегда. Для этого нужно поднять вторую виртуалку AWS и создать балансировщик.

И так далее.

Я не объясняю студенту, как настраивать nginx или SSH. Ему об этом расскажет ChatGPT. Но как понять, что ChatGPT дал корректный ответ? Для этого у студента должен быть хороший теоретический фундамент. Если конкретные задачи это первый столп методики, то изучение теории - второй. Для этого в рамках каждой задачи я даю студенту вопросы, ответы на которые он должен подготовить (тоже с помощью ChatGPT, скорее всего).

Когда студент всё сделал, мы созваниваемся. Он показывает результат и отвечает на вопросы. Я корректирую и даю дополнительную информацию. Так мы формируем системные фундаментальные знания. Они позволят понять, что, к примеру, nginx и traefik это просто разные инструменты, но они могут решать общую задачу - роутинг. И теперь опыт работы с nginx может быть переложен на traefik. Создаётся система знаний.

Вот примеры вопросов после первой задачи:

1. Что такое HTML?
2. Что такое HTTP? Как работает этот протокол?
3. Что такое веб-сервер?
4. Как пользоваться curl для отправки запросов по HTTP?
5. Как работает DNS?
6. Как устроена система пользователей и ролей в Linux?
7. Что такое процесс? Как nginx использует процессы для своей работы?

Вот примеры вопросов после второй задачи:

1. Что такое балансировка нагрузки? Какие варианты балансировки нагрузки существуют?
2. Что такое reversy proxy? Как можно настроить nginx для выполнения роли reverse proxy?
3. Что такое TCP/IP? Чем эти протоколы отличаются от HTTP?
4. Что такое пакетный менеджер? Какие есть пакетные менеджеры в дистрибутивах Linux? Как в деталях работают пакетные менеджеры?

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

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

Есть несколько способов изучения этих принципов, и один из них это чтение хороших книг. На мой взгляд, эталоном книги с фундаментальными знаниями является "Designing Data-Intensive Applications" Мартина Клеппмана (в русскоязычном сообществе известна под названием "Кабанчик") https://a.co/d/f2DYvKt. После её прочтения в голове формируется целостная картина принципов и технологий работы с данными. А это базы данных, очереди сообщений, кеши - всё то, что мы практически всегда используем в создаваемых нами системах. Каждый разработчик должен прочесть эту книгу.

И скоро выйдет второе издание! 🔥

Об этом автор книги Мартин Клеппман с соавтором второго издания Крисом Риккомини рассказали в сессии вопросов-ответов на Monster Scale Summit 2025 https://youtu.be/T-d1wR7adB8?si=jEVzB4w6eYE8Szz5. Кроме этого, они обсудили ряд современных трендов в работе с данными, таких как облачные хранилища, встроенные базы данных, расширения баз данных. Рекомендую к просмотру.

Что же нового будет во втором издании? Основной источник нового материала - это облачные технологии. С момента выхода первого издания книги прошло 8 лет, и за это время облачные хранилища данных, такие как AWS S3 и облачные БД, существенно повлияли на то, как мы проектируем системы работы с данными. Например, Grafana Loki, Tempo и Mimir используют не файловую систему, а объектные хранилища (AWS S3, Azure Blob Storage, Google Cloud Storage) для хранения данных. Этот тренд набирает популярность и нужно его систематизировать. Что и будет сделано во втором издании.

В общем, если вы ещё не читали "Кабанчика", то стоит подождать до декабря 2025 года, когда выйдет второе издание. А если читали, то тоже подождать и прочитать заново 🙂 И тогда можно не волноваться, что вас заменит ИИ. Наоборот, он станет вашим помощником, вместе с которым вы будете быстро создавать надёжные и производительные системы. 🚀