I am pleased to announce that the "CryptoBank Microservices" course has started! Yesterday, December 14th, we held a kick-off meeting where the participants met and discussed the course content. There are 30 participants from different cities of the world, including Astana, Almaty, Moscow, Novosibirsk, Limassol, Prague, and Tokyo.

The main goal of the course is to create a distributed .NET application using modern Software Development Life Cycle processes and tools. These include cloud providers, Terraform, Ansible, GitHub Actions, Nginx, Kubernetes, Helm, Prometheus, Elasticsearch, and many more.

We'll deeply research diverse architectural approaches differing in communication styles, data consistency types, and coordination models. This knowledge will allow the participants to understand each approach's trade-offs and applicability to specific business requirements. The tools learned along the way will include reactive programming, gRPC, Kafka, and RabbitMQ.

Another main topic is communication security. We'll learn about TLS, HTTPS, public key certificates, and PKI. Software engineers must understand how it works, so a systematic review is necessary. Moreover, we'll set up automatic certificate renewal with Automatic Certificate Management Environment (ACME) tools.

Last but not least is our journey in blockchain technologies. We'll look at Ethereum and its innovations, including the Ethereum Virtual Machine (EVM) and smart contracts.

The participants warmly received the denoscription of the course content. They understand these technologies and processes will allow them to become top specialists and successfully compete in the labor market. Motivation is high, so let's get started! 🚀

In the first part of the "CryptoBank Microservices" course, the participants use Infrastructure-as-Code tools to deploy their applications to a cloud environment. Everyone can choose a cloud provider at their own discretion.

Many factors influence the decision-making process, and pricing is one of them. Let's compare the prices of virtual machines offered by some popular providers. We'll use the configuration that is well-suited for most general-purpose workloads:

* 4 virtual CPUs
* 16 GB of RAM
* 150 GB of local SSD
* West Europe region

Here are the results:

* Azure offers D4ads instances for $182 per month per instance.
* AWS offers m5ad.xlarge instances for $193 per month per instance.
* Google Cloud offers c3-standard-4-lssd instances for $162 per month per instance.
* Hetzner Cloud offers CCX32 instances for $32 per month per instance.
* DigitalOcean uses no instance names and allows the configuration of each parameter. The instance with the given parameters costs $136 per month.
* Yandex Cloud uses no instance names as well. The instance with the given parameters costs $64 per month.

As you can see, prices vary greatly. You can save a lot of money if you take this into account when choosing a cloud provider.

The Drim Team members came up with the great idea of conducting mock interviews with each other. Without thinking twice, we planned the first one for February 7th. And then, every week, there will be more of them. Such interviews will allow each participant to understand what gaps there are in their knowledge and how to fill them.

Another important goal is to prepare for real interviews, in which our participants will prove themselves as high-class professionals. 🚀

It will be fun!

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