В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Архитектура ИТ-решений

3348 membersпожаловаться на группу
2021 July 16

A

Alex in Архитектура ИТ-решений
в разных случаях детали будут отличаться но посыл один - вам конец.

рассмотрим случай cloud архитектуры с использованием какой-нибудь платформы. пришел дата сатанист и выжрал своими тестами и примерками (именно это и есть релиз микросервиса) бюджет учетки, потому что на дефолтных настройках у него расчет идет две недели и ждать ему не хотелось, он накинул ядер, памяти...
источник
14:40пожаловаться#1

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Это не реально
Отчасти потому что новый сервис,  может потребовать новый инстанс БД или вообще другую СУБД
источник
14:40пожаловаться#2

A

Alex in Архитектура ИТ-решений
+
источник
14:41пожаловаться#3

SV

Sergey V in Архитектура ИТ-решений
Только ситхи возводят всё в абсолют )
источник
14:41пожаловаться#4

p

pragus in Архитектура ИТ-решений
Я там где-то выше писал что любой (микро)сервис должен иметь бюджеты.
источник
14:42пожаловаться#5

SV

Sergey V in Архитектура ИТ-решений
Новая БД это нетривиально, а если БД исключить из облака, уже можно и попробовать что-нибудь придумать с автоматизацией
источник
14:42пожаловаться#6

SV

Sergey V in Архитектура ИТ-решений
На уровне платформы причём, то есть вне самого сервиса
источник
14:42пожаловаться#7

p

pragus in Архитектура ИТ-решений
Проблема в том, что человек тут может спокойно накинуть ресурсов и ничем не лимитирован, что в корне неправильно.
источник
14:43пожаловаться#8

p

pragus in Архитектура ИТ-решений
И тесты/исследования должны быть под отдельной учёткой. Если прод и тесты черпают из одной бочки - быть беде.
источник
14:44пожаловаться#9

A

Alex in Архитектура ИТ-решений
проблема в том что разрабу дали (как указано в сообщении) возможность
когда программист самостоятельно может как-то в коде (репозитории) описать используемую инфраструктуру, а дальше все завертится без дополнительного вмешательства, отдельного нового разворачивания и прочего
источник
14:44пожаловаться#10

p

pragus in Архитектура ИТ-решений
Нет, не проблема. Описать в рамках лимитов - ок. А вот прыгнуть выше бюджета - это надо апрув.
источник
14:45пожаловаться#11

SV

Sergey V in Архитектура ИТ-решений
Само по себе это не есть плохо. Мы же даём программисту писать код, в конце-концов.
источник
14:45пожаловаться#12

A

Alex in Архитектура ИТ-решений
а еще мы задаем рамки, внутри которых создается и живет код, рамки, за которыми хаос и разруха
источник
14:46пожаловаться#13

SV

Sergey V in Архитектура ИТ-решений
Да
источник
14:46пожаловаться#14

A

Alex in Архитектура ИТ-решений
одна из этих рамок - не создавать новые системы и компоненты систем по желанию разраба
источник
14:47пожаловаться#15

SV

Sergey V in Архитектура ИТ-решений
Ну, тут уже у кого какие рамки
источник
14:47пожаловаться#16

A

Alex in Архитектура ИТ-решений
из своего кармана разраб может что угодно делать, а в рамках проекта разраб не управляет бюджетом
источник
14:47пожаловаться#17

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ещё раз
Границы (размеры) модулей/сервисов прежде всего определяются декомпозицией (функциональными соображениями), и потом нефункциональными (в том числе производительность, развёртываемость и и.д., и т.п.)

Иными словами, не столь важно, какой размер, важно чтобы границы были правильными в данном контексте (соотв текущим требованиям, в том числе к развиваемости)
источник
14:48пожаловаться#18

p

pragus in Архитектура ИТ-решений
Я выше писал, попробую переформулировать: вы даёте какой-то дефолт лимитов для каждого нового сервиса. Это то, сколько вы готовы апрувнуть не глядя.
Если при просят больше, это надо согласовывать. Можно рассматривать как приемлемый уровень фрода.
источник
14:50пожаловаться#19

GK

Gennadiy Kruglov in Архитектура ИТ-решений
К вопросу о доменных сервисах

В МСА так и не сформулировали principles & benefits, а также так и не разработали таксономию сервисов

Какую-то таксономию предложил Марк Ричардс в книге Microservices vs Service-Oriented Architecture
источник
15:20пожаловаться#20