Инженерная культура и технологический стек Леруа Мерлен
https://leroymerlin-tech.ru/
#techstack #engineering_culture
https://leroymerlin-tech.ru/
#techstack #engineering_culture
Леруа Мерлен Цифровые Технологии
Леруа Мерлен Цифровые Технологии — технологическая компания-платформа
Cтроим технологическую компанию-платформу. 20 направлений, в которых работают 700+ инженеров. Делимся опытом, рассказываем об ошибках и новых проектах. Присоединяйся к нам!
Открытый справочник команды разработки в Авито:
- ценности,
- бизнес-процессы,
- стандарты,
- процедуры и правила
https://github.com/avito-tech/playbook
#playbook #engineering_culture #techstack
- ценности,
- бизнес-процессы,
- стандарты,
- процедуры и правила
https://github.com/avito-tech/playbook
#playbook #engineering_culture #techstack
GitHub
GitHub - avito-tech/playbook: AvitoTech team playbook
AvitoTech team playbook. Contribute to avito-tech/playbook development by creating an account on GitHub.
This media is not supported in your browser
VIEW IN TELEGRAM
День из жизни архитектора решений 😂 #fun
🚀 Интересные выжимки из исследования The State of Developer Ecosystem 2023 от JetBrains
🤖 Использование генеративного ИИ в разработке
- 77% разработчиков используют ChatGPT.
- 46% используют GitHub Copilot.
- Наиболее частое использование: общие вопросы о разработке на естественном языке.
📈 Изменения в популярности языков программирования
- JavaScript теряет популярность (незначительно).
- Rust набирает обороты, стремясь заменить C++.
- Топ-5 языков: JavaScript, Python, HTML/CSS, SQL, Java.
💰 Доля высокооплачиваемых сотрудников по должностям (Top 6)
- 59% - архитектор (!)
- 52% - CIO / CEO / CTO
- 49% - Team Lead
- 40% - DevOps Engineer / Infrastructure Developer
- 35% - Product Manager / Marketing Manager
- 32% - Developer / Programmer / Software Engineer
💰 Тренды зарплат разработчиков
- Самые высокооплачиваемые: Scala, Go, Kotlin.
📚 Источники для изучения новых технологий
- 67% читают документацию и API.
- 53% используют блоги/форумы.
- 40% читают книги.
🔍 Также интересно
- 34% разрабатывают микросервисы.
- 61% генерируют API, в основном через Swagger (84%).
- 49% разработчиков под мобильные устройства используют кросс-платформенные технологии: 46% Flutter, 35% React Native.
🔗 [Подробнее об исследовании](https://www.jetbrains.com/lp/devecosystem-2023/)
🤖 Использование генеративного ИИ в разработке
- 77% разработчиков используют ChatGPT.
- 46% используют GitHub Copilot.
- Наиболее частое использование: общие вопросы о разработке на естественном языке.
📈 Изменения в популярности языков программирования
- JavaScript теряет популярность (незначительно).
- Rust набирает обороты, стремясь заменить C++.
- Топ-5 языков: JavaScript, Python, HTML/CSS, SQL, Java.
💰 Доля высокооплачиваемых сотрудников по должностям (Top 6)
- 59% - архитектор (!)
- 52% - CIO / CEO / CTO
- 49% - Team Lead
- 40% - DevOps Engineer / Infrastructure Developer
- 35% - Product Manager / Marketing Manager
- 32% - Developer / Programmer / Software Engineer
💰 Тренды зарплат разработчиков
- Самые высокооплачиваемые: Scala, Go, Kotlin.
📚 Источники для изучения новых технологий
- 67% читают документацию и API.
- 53% используют блоги/форумы.
- 40% читают книги.
🔍 Также интересно
- 34% разрабатывают микросервисы.
- 61% генерируют API, в основном через Swagger (84%).
- 49% разработчиков под мобильные устройства используют кросс-платформенные технологии: 46% Flutter, 35% React Native.
🔗 [Подробнее об исследовании](https://www.jetbrains.com/lp/devecosystem-2023/)
JetBrains: Developer Tools for Professionals and Teams
The State of Developer Ecosystem in 2023 Infographic
Learn about the latest trends in tools, technologies, AI, and programming languages.
Forwarded from KazDevOps
Насколько быстрее и эффективнее работает Kubernetes на bare-metal и на виртуальных машинах.
Тесты показали, что кластер, развернутый на bare-metal:
➖ в 2 раза производительнее по части CPU и в 3 по части ОЗУ, так как дополнительные уровни на VM потребляют физический процессор и оперативную память для работы, отнимая часть вычислительных мощностей от рабочих нагрузок.
➖ Производительность хранилища более чем в 2 раза выше. При работе с базой данных размером 8 ГБ задержка кластера виртуальных машин составляла 34,78 мс, а у кластера «голого железа» — 18,17 мс. Чем больше БД, тем больше разрыв.
➖ Производительность внутренней сети кластера лучше более чем в 5 раз. Пропускная способность кластера VM варьировалась от 862 КБ/с при MSS=1 до 6,52 МБ/с при MSS=8, а на голом железе — от 4,17 МБ/с до 31 МБ/с при тех же значениях MSS.
🚩 В продуктовых средах результаты могут отличаться, но для максимума производительности вариант с физическим железом привлекательнее.
#devops #k8s #kubernetes
@DevOpsKaz
Тесты показали, что кластер, развернутый на bare-metal:
➖ в 2 раза производительнее по части CPU и в 3 по части ОЗУ, так как дополнительные уровни на VM потребляют физический процессор и оперативную память для работы, отнимая часть вычислительных мощностей от рабочих нагрузок.
➖ Производительность хранилища более чем в 2 раза выше. При работе с базой данных размером 8 ГБ задержка кластера виртуальных машин составляла 34,78 мс, а у кластера «голого железа» — 18,17 мс. Чем больше БД, тем больше разрыв.
➖ Производительность внутренней сети кластера лучше более чем в 5 раз. Пропускная способность кластера VM варьировалась от 862 КБ/с при MSS=1 до 6,52 МБ/с при MSS=8, а на голом железе — от 4,17 МБ/с до 31 МБ/с при тех же значениях MSS.
🚩 В продуктовых средах результаты могут отличаться, но для максимума производительности вариант с физическим железом привлекательнее.
#devops #k8s #kubernetes
@DevOpsKaz
Список лучших программных продуктов в 2024 году по версии G2 (занимается обзорами программного обеспечения и услуг)
Из интересного в списке 100 лучших продуктов из 9 700 (место - название):
9 - Google Analytics (34-е место в отдельном списке Продукты для предприятий)
21 - TikTok Ads
30 - AWS Cloud Formation
32 - Notion
46 - Jira (10-е место в отдельном списке Продукты для предприятий)
50 - Confluence (1-е место в отдельном списке Продукты для предприятий)
52 - Miro (17-е место в отдельном списке Продукты для предприятий)
60 - Spring Boot
69 - Trello
75 - Amplitude
https://www.g2.com/best-software-companies
#ranking
Из интересного в списке 100 лучших продуктов из 9 700 (место - название):
9 - Google Analytics (34-е место в отдельном списке Продукты для предприятий)
21 - TikTok Ads
30 - AWS Cloud Formation
32 - Notion
46 - Jira (10-е место в отдельном списке Продукты для предприятий)
50 - Confluence (1-е место в отдельном списке Продукты для предприятий)
52 - Miro (17-е место в отдельном списке Продукты для предприятий)
60 - Spring Boot
69 - Trello
75 - Amplitude
https://www.g2.com/best-software-companies
#ranking
G2
Best Software Products for 2024 | G2
Looking for the Best Software Products for 2024? G2’s annual Best Software Products list is here to help you make the best decision for your business.
The Top 100+ Developer Tools 2023
Для формирования списка команда StackShare проанализировала более 12 миллионов отзывов на своем портале.
https://stackshare.io/posts/top-developer-tools-2023
#ranking
Для формирования списка команда StackShare проанализировала более 12 миллионов отзывов на своем портале.
https://stackshare.io/posts/top-developer-tools-2023
#ranking
StackShare
🏆 The Top 100 Developer Tools of 2023 | StackShare
🌐 IANA официально зарегистрировала медиа тип application/yaml 📄, подчеркивая его широкое применение для сериализации данных в удобном для человека формате
🔍 Приложения, использующие этот media type:
- Приложения, которым необходим удобный для пользователя межъязыковой язык сериализации данных на основе Юникода, разработанный на основе общих типов данных динамических языков программирования.
- В контексте web-API YAML широко используется как более компактный способ сериализации контента, предназначенного для использования, в соответствии с моделью данных JSON. Типичными примерами являются спецификации OpenAPI и файлы манифеста Kubernetes, которые можно сериализовать в обоих форматах.
💡 Почему важно?
- Без официального признания разработчики и архитекторы могли столкнуться с несоответствиями в обработке YAML-данных между различными системами и приложениями, что усложняло обмен данными и интеграцию.
- Официальная регистрация обеспечивает единый стандарт обработки и безопасности, повышая совместимость и безопасность при использовании YAML в различных проектах.
🔗 Детали на сайте IANA:
iana.org/assignments/media-types/application/yaml
#api #yaml
На связи с вами https://t.me/itarchitecture
🔍 Приложения, использующие этот media type:
- Приложения, которым необходим удобный для пользователя межъязыковой язык сериализации данных на основе Юникода, разработанный на основе общих типов данных динамических языков программирования.
- В контексте web-API YAML широко используется как более компактный способ сериализации контента, предназначенного для использования, в соответствии с моделью данных JSON. Типичными примерами являются спецификации OpenAPI и файлы манифеста Kubernetes, которые можно сериализовать в обоих форматах.
💡 Почему важно?
- Без официального признания разработчики и архитекторы могли столкнуться с несоответствиями в обработке YAML-данных между различными системами и приложениями, что усложняло обмен данными и интеграцию.
- Официальная регистрация обеспечивает единый стандарт обработки и безопасности, повышая совместимость и безопасность при использовании YAML в различных проектах.
🔗 Детали на сайте IANA:
iana.org/assignments/media-types/application/yaml
#api #yaml
На связи с вами https://t.me/itarchitecture
📊 Как выбрать правильный график для представления данных
🔍 Подготовка презентации с данными результатов своего труда и труда команды - практически ежедневная работа любого архитектора. Между тем навигация в мире визуализации данных иногда может казаться попыткой разгадать головоломку.
🔍 Вот простая схема, которая поможет вам выбрать идеальный график для вашего повествования о данных. Независимо от того, работаете ли вы с категориями или непрерывными числами, хотите ли вы выделить тенденции, сравнить несколько наборов данных или просто представить точки данных ясно и кратко, эта схема поможет вам.
📈 Круговые диаграммы для частей целого, линейные графики для анализа тенденций во времени, тепловые карты для метрических данных и многое другое - все дело в том, чтобы найти подходящее визуальное представление для вашей информации. Поэтому в следующий раз, когда вы готовитесь к презентации или отчету, используйте этот удобный справочник и позвольте представить данные максимально емко и доступно.
#data_visualisation #presentation #graph
На связи с вами https://t.me/itarchitecture
🔍 Подготовка презентации с данными результатов своего труда и труда команды - практически ежедневная работа любого архитектора. Между тем навигация в мире визуализации данных иногда может казаться попыткой разгадать головоломку.
🔍 Вот простая схема, которая поможет вам выбрать идеальный график для вашего повествования о данных. Независимо от того, работаете ли вы с категориями или непрерывными числами, хотите ли вы выделить тенденции, сравнить несколько наборов данных или просто представить точки данных ясно и кратко, эта схема поможет вам.
📈 Круговые диаграммы для частей целого, линейные графики для анализа тенденций во времени, тепловые карты для метрических данных и многое другое - все дело в том, чтобы найти подходящее визуальное представление для вашей информации. Поэтому в следующий раз, когда вы готовитесь к презентации или отчету, используйте этот удобный справочник и позвольте представить данные максимально емко и доступно.
#data_visualisation #presentation #graph
На связи с вами https://t.me/itarchitecture
Модульные монолиты можно быстро выделить в микросервисы
Необходимо заменить логические границы физическими.
Для этого нужны:
- Четко определенные границы модуля
- Способ взаимодействия модулей
- Хорошая изоляция данных в базе данных.
Миграция сводится к извлечению модуля в новый сервис.
Также потребуется переместить таблицы базы данных в отдельную базу данных.
На этом этапе необходимо разместить обратный прокси-сервер для маршрутизации входящего трафика между микросервисами.
Это скроет детали реализации системы от клиентских приложений.
Или вы можете использовать управляемую облачную службу для шлюза API и балансировки нагрузки.
А как насчет межмодульных коммуникаций?
Если вы ранее реализовали связь с помощью вызовов методов, это больше не будет работать. Вам придется заменить эту реализацию HTTP-вызовами по сети. В игру вступают аутентификация и отказоустойчивость.
Если вы используете обмен сообщениями для межмодульного взаимодействия, это упрощает переход на микросервисы. Однако цена этого подхода — повышенная сложность на начальном этапе.
Этот процесс перехода на микросервисы следует паттерну Strangler.
#patterns #microservices
На связи с вами https://t.me/itarchitecture
Необходимо заменить логические границы физическими.
Для этого нужны:
- Четко определенные границы модуля
- Способ взаимодействия модулей
- Хорошая изоляция данных в базе данных.
Миграция сводится к извлечению модуля в новый сервис.
Также потребуется переместить таблицы базы данных в отдельную базу данных.
На этом этапе необходимо разместить обратный прокси-сервер для маршрутизации входящего трафика между микросервисами.
Это скроет детали реализации системы от клиентских приложений.
Или вы можете использовать управляемую облачную службу для шлюза API и балансировки нагрузки.
А как насчет межмодульных коммуникаций?
Если вы ранее реализовали связь с помощью вызовов методов, это больше не будет работать. Вам придется заменить эту реализацию HTTP-вызовами по сети. В игру вступают аутентификация и отказоустойчивость.
Если вы используете обмен сообщениями для межмодульного взаимодействия, это упрощает переход на микросервисы. Однако цена этого подхода — повышенная сложность на начальном этапе.
Этот процесс перехода на микросервисы следует паттерну Strangler.
#patterns #microservices
На связи с вами https://t.me/itarchitecture
https://www.youtube.com/watch?v=POIbWZh68Cg&ab_channel=%D0%9A%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8FArchDays
#architecture_as_code #plantuml #c4
На связи с вами https://t.me/itarchitecture
#architecture_as_code #plantuml #c4
На связи с вами https://t.me/itarchitecture
YouTube
Раз архитектура — «as Code», почему бы её не покрыть тестами?! Руслан Сафин.
Выступление на ArchDays 2023. Забронируйте участие на следующей конференции: https://archconf.ru/arch
Раз уж микросервисная архитектура теперь «as code» (расскажу как это сделать, например, с помощью plantuml), то на неё можно и нужно писать тесты! :)
Рассмотрим…
Раз уж микросервисная архитектура теперь «as code» (расскажу как это сделать, например, с помощью plantuml), то на неё можно и нужно писать тесты! :)
Рассмотрим…
Тестовые окружения
dev / staging / production / mix и tooling
https://pca.st/episode/0f31a3cf-8da4-4880-a96e-95734e8f11db
#podcast #devops #testing
На связи с вами https://t.me/itarchitecture
dev / staging / production / mix и tooling
https://pca.st/episode/0f31a3cf-8da4-4880-a96e-95734e8f11db
#podcast #devops #testing
На связи с вами https://t.me/itarchitecture
Pocket Casts
Podlodka #360 – Тестовые окружения - Podlodka Podcast
Podlodka – это еженедельное аудио-шоу про IT и все, что с ним связано. Формат наших выпусков - это полное погружение в тему вместе с приглашенным гостем. В каждый выпуск мы зовём интересных и именитых профессионалов в разных областях.
Мы любим обсуждать…
Мы любим обсуждать…
🚀 Shopify заработала около 7 миллиардов долларов в 2023 году.
🔧 С помощью монолитного приложения на Ruby on Rails.
🤔 Получается, можно далеко зайти и без микросервисов, правда?
📜 Основной монолит содержит более 3 миллионов строк кода.
🔩 Shopify организует свой монолит в кодовые блоки, называемые компонентами. Компоненты созданы путём сортировки тысяч файлов в несколько десятков категорий, каждая из которых представляет свой домен и разделена на директории с названиями вроде:
- Доставка
- Интернет-магазин
- Товарное обеспечение
- Оформление покупок
🔄 Но не всегда было так.
🚧 Монолит Shopify начался с группировки компонентов на основе технических вопросов. С течением времени поддержка становилась всё более сложной и замедляла работу команды.
💡 Что-то должно было измениться.
🏗 Затем началась многолетняя работа:
- Компонентизация монолита
- Изоляция зависимостей между компонентами
👇 Вывод:
Хорошо определённые внутрипроцессные компоненты (модули) могут стать отличным промежуточным шагом к внепроцессным компонентам (сервисам).
#monolith #ddd
На связи с вами https://t.me/itarchitecture
🔧 С помощью монолитного приложения на Ruby on Rails.
🤔 Получается, можно далеко зайти и без микросервисов, правда?
📜 Основной монолит содержит более 3 миллионов строк кода.
🔩 Shopify организует свой монолит в кодовые блоки, называемые компонентами. Компоненты созданы путём сортировки тысяч файлов в несколько десятков категорий, каждая из которых представляет свой домен и разделена на директории с названиями вроде:
- Доставка
- Интернет-магазин
- Товарное обеспечение
- Оформление покупок
🔄 Но не всегда было так.
🚧 Монолит Shopify начался с группировки компонентов на основе технических вопросов. С течением времени поддержка становилась всё более сложной и замедляла работу команды.
💡 Что-то должно было измениться.
🏗 Затем началась многолетняя работа:
- Компонентизация монолита
- Изоляция зависимостей между компонентами
👇 Вывод:
Хорошо определённые внутрипроцессные компоненты (модули) могут стать отличным промежуточным шагом к внепроцессным компонентам (сервисам).
#monolith #ddd
На связи с вами https://t.me/itarchitecture
🔹 Микрофронтенды могут быть использованы, если используются микросервисы 🔹
Микрофронтенды — это микросервисы для фронтендов, но с другим подходом.
Если реализация фронтенда сложная и команда разработки большая, это может быть аргументом в пользу микрофронтендов.
Представьте, что один фрагмент кода фронтенда отвечает за рендеринг интенсивного пользовательского интерфейса и может заблокировать основной поток и вызвать сбой приложения.
Здесь вы можете обернуть этот интерфейс в отдельный микрофронтенд и рендерить его независимо, и приложение будет работать как обычно.
Чаще всего несколько команд работают над одним фронтенд-кодом, как монолит или модульный фронтенд-код.
Микрофронтенды предполагают разделение фронтенда на несколько микроприложений.
Так каждая команда, работающая над разными функциями, может:
1. Независимо работать над пользовательским интерфейсом.
2. Не зависеть от других команд.
3. Использовать общие ресурсы, такие как внутренняя библиотека для обмена компонентами или атомами.
Для создания каждого микрофронтенда можно использовать React, Angular или Vue. Но в целом надо понимать, что эта парадигма внесет анархии в ваши процессы разработки.
Таким образом, в больших командах фронтенда это помогает всем поделить пользовательский интерфейс, работать независимо и запускать в продакшн.
Но если фронтенд-приложение/код не слишком обширен, то микрофронтенды избыточны.
#microfrontend #microservice #frontend #uiux
На связи с вами https://t.me/itarchitecture
Микрофронтенды — это микросервисы для фронтендов, но с другим подходом.
Если реализация фронтенда сложная и команда разработки большая, это может быть аргументом в пользу микрофронтендов.
Представьте, что один фрагмент кода фронтенда отвечает за рендеринг интенсивного пользовательского интерфейса и может заблокировать основной поток и вызвать сбой приложения.
Здесь вы можете обернуть этот интерфейс в отдельный микрофронтенд и рендерить его независимо, и приложение будет работать как обычно.
Чаще всего несколько команд работают над одним фронтенд-кодом, как монолит или модульный фронтенд-код.
Микрофронтенды предполагают разделение фронтенда на несколько микроприложений.
Так каждая команда, работающая над разными функциями, может:
1. Независимо работать над пользовательским интерфейсом.
2. Не зависеть от других команд.
3. Использовать общие ресурсы, такие как внутренняя библиотека для обмена компонентами или атомами.
Для создания каждого микрофронтенда можно использовать React, Angular или Vue. Но в целом надо понимать, что эта парадигма внесет анархии в ваши процессы разработки.
Таким образом, в больших командах фронтенда это помогает всем поделить пользовательский интерфейс, работать независимо и запускать в продакшн.
Но если фронтенд-приложение/код не слишком обширен, то микрофронтенды избыточны.
#microfrontend #microservice #frontend #uiux
На связи с вами https://t.me/itarchitecture
This media is not supported in your browser
VIEW IN TELEGRAM
🔄 Репликация базы данных необходима для обеспечения надежности, но она также может вызвать задержку репликации
Но что же такое "задержка репликации"?
В типичной конфигурации репликации с ведущим узлом все операции записи направляются на основной узел.
Тем не менее, запросы на чтение могут обрабатываться любой репликой (включая основную в некоторых случаях).
Это хорошо, потому что вы можете масштабировать операции чтения, добавляя больше реплик.
Но для получения полного преимущества от репликации используется асинхронная репликация.
Однако, когда ваше приложение читает данные с асинхронной реплики, существует большая вероятность, что оно может получить устаревшую информацию, если реплика по какой-то причине отстала.
📝 Например:
1️⃣ Пользователь А отправляет запрос на обновление (запись) на основной или ведущий узел.
2️⃣ Ведущий узел отправляет новую информацию своим репликам.
3️⃣ Реплика 1 обновляется.
4️⃣ Однако пользователь B запрашивает (читает) данные с реплики 2 и получает устаревшую информацию.
5️⃣ Позже реплика 2 в конечном итоге обновляется.
Задержка между моментом выполнения записи на ведущем узле и её отражением на подчиненном узле известна как "задержка репликации".
Задержка может составлять всего лишь долю секунды (практически незаметно).
Однако, если система работает на пределе своих возможностей, задержка также может увеличиться до нескольких секунд или даже минут.
🚨 Таким образом, основная проблема - несоответствие данных для пользователей:
1. Пользователь B может неоднократно читать данные и видеть разные результаты из-за задержки репликации.
2. Пользователь А, сделавший запись, может получить устаревшие данные при чтении с реплики.
#databases #replica #eventual_consistency
На связи с вами https://t.me/itarchitecture
Но что же такое "задержка репликации"?
В типичной конфигурации репликации с ведущим узлом все операции записи направляются на основной узел.
Тем не менее, запросы на чтение могут обрабатываться любой репликой (включая основную в некоторых случаях).
Это хорошо, потому что вы можете масштабировать операции чтения, добавляя больше реплик.
Но для получения полного преимущества от репликации используется асинхронная репликация.
Однако, когда ваше приложение читает данные с асинхронной реплики, существует большая вероятность, что оно может получить устаревшую информацию, если реплика по какой-то причине отстала.
📝 Например:
1️⃣ Пользователь А отправляет запрос на обновление (запись) на основной или ведущий узел.
2️⃣ Ведущий узел отправляет новую информацию своим репликам.
3️⃣ Реплика 1 обновляется.
4️⃣ Однако пользователь B запрашивает (читает) данные с реплики 2 и получает устаревшую информацию.
5️⃣ Позже реплика 2 в конечном итоге обновляется.
Задержка между моментом выполнения записи на ведущем узле и её отражением на подчиненном узле известна как "задержка репликации".
Задержка может составлять всего лишь долю секунды (практически незаметно).
Однако, если система работает на пределе своих возможностей, задержка также может увеличиться до нескольких секунд или даже минут.
🚨 Таким образом, основная проблема - несоответствие данных для пользователей:
1. Пользователь B может неоднократно читать данные и видеть разные результаты из-за задержки репликации.
2. Пользователь А, сделавший запись, может получить устаревшие данные при чтении с реплики.
#databases #replica #eventual_consistency
На связи с вами https://t.me/itarchitecture
📢 Картинка стоит тысячи слов: 9 лучших практик разработки микросервисов
При разработке микросервисов необходимо следовать следующим лучшим практикам:
🗃️ 1. Используйте отдельное хранилище данных для каждого микросервиса
📈 2. Сохраняйте код на том же уровне зрелости
🛠️ 3. Отдельная сборка для каждого микросервиса
✅ 4. Назначьте каждому микросервису одну ответственность
📦 5. Развертывайте в контейнеры
🌀 6. Проектируйте сервисы без сохранения состояния
🎯 7. Применяйте предметно-ориентированное проектирование
🔗 8. Разрабатывайте микрофронтенды (https://t.me/itarchitecture/281)
🏗️ 9. Обеспечьте оркестирование микросервисов (https://t.me/itarchitecture/152)
#microservice
На связи с вами https://t.me/itarchitecture
При разработке микросервисов необходимо следовать следующим лучшим практикам:
🗃️ 1. Используйте отдельное хранилище данных для каждого микросервиса
📈 2. Сохраняйте код на том же уровне зрелости
🛠️ 3. Отдельная сборка для каждого микросервиса
✅ 4. Назначьте каждому микросервису одну ответственность
📦 5. Развертывайте в контейнеры
🌀 6. Проектируйте сервисы без сохранения состояния
🎯 7. Применяйте предметно-ориентированное проектирование
🔗 8. Разрабатывайте микрофронтенды (https://t.me/itarchitecture/281)
🏗️ 9. Обеспечьте оркестирование микросервисов (https://t.me/itarchitecture/152)
#microservice
На связи с вами https://t.me/itarchitecture