Языки и архитектура: как важно быть агностиком языка и архитектуры
programming microservices monolith ruby

Языки и архитектура: как важно быть агностиком языка и архитектуры

30 декабря 2023 г.

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

Основная

Во-первых, я наблюдаю, что мир серверной части заново открывает себя и критикует архитектуру микросервисов. Например: Amazon Prime недавно вернулся к монолитной структуре. Для меня ключевая идея заключается в том, что мы не должны слепо следовать всем основным тенденциям. Скорее, нам следует тщательно решить, какую архитектуру выбрать. Возможно, оптимальным решением для вас будет либо придерживаться монолита, либо найти баланс между монолитом и микросервисами.

Source: Twitter

После этого Тоби продемонстрировал, что Rails теперь может быть быстрым и демонстрировать высокую производительность. Давайте углубимся в это. Ruby on Rails часто рассматривается как основа для стартапов, обеспечивающая более быструю разработку новых функций — и эта репутация сохраняется. Однако, когда современный Ruby сочетается с современными Rails, в умелых руках он может обеспечить скорость даже на поздних стадиях жизненного цикла продукта.

Теперь давайте рассмотрим PHP. У этого языка плохая репутация, поскольку у него низкие границы для входа, и если вы хотите добиться быстрой и дешевой разработки продукта, вы можете сделать это с помощью PHP. За свою карьеру я видел, что спагетти-код и мутантную архитектуру можно создавать даже на модном Golang или на старомодном C#/Java. Следовательно, проекты с низкой ремонтопригодностью могут быть независимыми от языка и архитектуры.

Примеры

Несколько лет назад я присоединился к проекту, который был переписан с Java на Golang (от монолита к микросервисам). Однако команда решила сначала переписать код на другой язык, а затем извлечь из него микросервисы. Я думаю, что это решение было принято потому, что Golang — это модно, и использовать его и микросервисы — это круто. Однако прогресс был остановлен, когда были реализованы несколько микросервисов (таких как авторизация и некоторые другие пользовательские сервисы). Итак, после некоторого улучшения скорости за счет более быстрого входа в систему и улучшения работоспособности базы данных. Мы оказались в тупике с огромным полумонолитным наследием в Golang, которое было трудно понять новичкам в этом проекте. Кроме того, было сложно продавать непрерывное извлечение микросервисов предприятиям, которым было бы достаточно монолитной архитектуры и Golang. н

Кроме того, я могу привести положительный пример, когда база данных с более чем 10 ТБ была разделена на отдельные базы данных, каждая из которых служит определенным целям и поддерживает отдельные микросервисы. Изначально это был монолит Ruby on Rails, но из-за роста нагрузки некоторые компоненты были извлечены и перенесены в микросервисы Golang. Эти изменения привели к увеличению скорости разработки и добавили возможность выдерживать высокие нагрузки

Советы

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

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

Заключение

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

Какой будет ваш выбор?

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE