Схема архитектуры программы это

Прежде чем заняться разработкой собственного проекта на основе каркаса приложения Laravel, нам неплохо было бы понять архитектуру каркаса приложения. Некоторые могут спросить: Зачем это нужно? Смысл забивать себе голову разной теоретической чепухой?
Постараюсь ответить на этот вопрос примером из жизни:

Представьте себе, что вы хотите иметь эксклюзивный автомобиль. Естественно он будет строиться на базе некоей серийной модели, но для того, чтобы его построить вам потребуется помощь людей, которые умеют это делать. Вы решаете обратиться к мастерам или даже к фирмам, у которых есть все необходимое: знания, опыт, оборудование и инструмент, но их услуги не дешевы, Ваш бюджет просто не выдержит таких расходов. Тогда вы решаете, что будете строить автомобиль самостоятельно. Отличное решение — правда, вы берете в руки инструмент, плюете на изучение теории, внедряете свои задумки и в итоге…

Я думаю, не стоит описывать, что у вас получится в итоге, ясно только одно — ничего хорошего.

Создаем масштабируемую архитектуру

Ну и более приближенный к теме Laravel 4 ответ: Понимание архитектуры приложения, знание основ паттернов (шаблонов) проектирования, помогут вам понять, почему следует использовать именно этот каркас web-приложения, оценить его слабые и сильные стороны. Так же вы получите ответ, почему так сильно изменился Laravel 4 по сравнению с Laravel 3.

Для тех, кто все же решил изучить теорию, прежде чем приступить к практике, советую: запаситесь терпением.

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

Определения

• Архитектура приложения — это логическая структура, описывающая отдельные компоненты, их свойства и связи в виде единой системы.
• Паттерны — это описания схем детализации отдельных подсистем приложения и взаимосвязей между ними. При этом паттерны не являются частью программы, не влияют прямо на ее структуру и сохраняют полную независимость от языка программирования конкретной системы.
• MVC — программная парадигма архитектурных паттернов: модель — представление — контроллер.

Паттерны это не так сложно как кажется

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

На самом деле паттерны не так сложны для понимания, как кажется на первый взгляд. Давайте проиллюстрируем их примерами, все сразу станет намного понятнее.

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

#Архитектура приложения и кода

1. Вася и Петя встретились.
2. Вася протянул Пете руку.
3. Петя сказал «Здравствуй Вася» .
4. Вася ответил «Здравствуй Петя» .
5. Вася спросил «Ты принес мне диск с курсовой?» .
6. Петя ответил «Да, принес» .
7. Вася полез в карман и достал деньги.
8. Вася отсчитал 100$.
9. Вася передал деньги Пете.
10. Петя принял деньги от Васи.
11. Петя пересчитал деньги.
12. Петя кивнул головой — подтверждая, что сумма соответствует цене за диск.
13. Петя положил деньги в карман.
14. Петя достал диск.
15. Петя передал диск Васе.
16. Вася принял диск от Пети.
17. Вася положил диск в карман.

Теперь разобьём эту программу на отдельные части:

1. Начало программы.
2. Встреча.
3. Обмен приветствиями.
4. Проверка наличия «данных» .
5. Передача данных «деньги» .
6. Списание данных «деньги» .
7. Проверка данных «деньги» .
8. Запись данных «деньги» .
9. Передача данных «диск» .
10. Списание данных «диск» .
11. Запись данных «диск» .
12. Конец программы.

У нас получился алгоритм действий для встречи и обмена диска на деньги между двумя индивидуумами.

Теперь разбиваем алгоритм на составляющие так:

1. Общение.
2. Обмен данными.
3. Проверка условий.
4. Действия.

У нас как раз и получился набор паттернов (правда очень абстрактный). Зато этот архитектурный паттерн или программная парадигма описывает обмен данными практически любого вида и любой сложности. По сути это аналог всем известного MVC .

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

Давайте попробуем составить схему таких паттернов самостоятельно:

1. Общение

1. Установление контакта
2. Передача запросов между пользователем и системой

1. Передача данных запроса в направлении в систему
2. Передача данных запроса в направлении из системы
3. Передача команд на проверку условий
4. Передача команд на передачу данных

1. Проверка условий передачи данных
2. Подтверждение проверки условий

1. Извлечение данных из хранилища «А»
2. Передача данных в хранилище «А»

В итоге у нас получилась своя схема паттернов.

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

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

Паттерны бывают разными

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

• Классификация по масштабу
• Классификация по стилю
• Классификация по применению

Классификация по масштабу

Самая часто используемая классификация — это классификация по масштабу. Чаще всего она применяется для паттернов проектирования и делится на три слоя по детализации:

• Архитектурные паттерны — наивысший слой детализации, используются для описания структуры программы в целом.
• Паттерны проектирования — средний слой детализации, описывают компоненты отдельных архитектурных паттернов и реализацию их взаимодействия.
• Идиомы — низший слой детализации, описывают реализацию отдельных решений проблем применительно к конкретному языку программирования. Следует учитывать, что зачастую идиомы для различных языков программирования имеют различную реализацию, или не имеют таковой вовсе. Примером могут служить указатели в памяти для реализации в Assembler, они имеют абсолютно другую реализацию в Си и не имеют реализации в С#, так как там проблема с утечкой памяти не существует ибо есть мусора.

Классификация по стилю

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

Классификация по применению

Программистам редко приходится сталкиваться с данным классом паттернов, но все же стоит о нем упомянуть, чтобы иметь хотя бы общее представление. Это самый высокоуровневый класс паттернов. В него входят целые классы паттернов. Например:

• Паттерны тестирования
• Паттерны документирования
• Паттерны организации производственных процессов
• Паттерны организации рабочих мест

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

Заключение

Какие преимущества дают нам паттерны? Отвечу на этот вопрос, цитируя John Vlissides ( Влиссидес):

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

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

Для тех, кого заинтересовали паттерны, советую найти и почитать книги:

• Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес: Приемы ООП. проектирования.
• Джон Влиссидес: шаблонов проектирования. Дополнительные штрихи.

Как вы считаете, полезен ли этот материал? Да Нет

Статистика: Символов — 9 119/7 861 без пробелов (8 947/7 711 без кода):, слов — 1 237

Наверх Опечатка? Выдели и нажми Ctrl+Enter (Orphus.ru)

Источник: laravel.ru

Аналитик и архитектура: UML-диаграммы для модели C4

Хотя профессиональные задачи системного и бизнес-аналитика отличаются от тех, которые решает ИТ-архитектор, знакомство с основными принципами описания архитектуры программной системы будет полезно всем этим специалистам. Разбираемся, зачем придумана модель C4, чем она отличается от модели 4+1 и можно ли все это описать в виде UML-диаграмм.

Что такое модель 4+1 и при чем здесь UML

С одной стороны, набором UML-диаграмм можно описать практически все аспекты программной системы, что мы рассматривали здесь и здесь. С другой стороны, UML предполагает только объектно-ориентированную парадигму, имеет строгие правила записи и ограниченный алфавит нотаций. Кроме того, некоторые аспекты, связанные с проектированием, разработкой, внедрением и эксплуатацией ПО остаются за рамками этого универсального языка моделирования. Чтобы обойти эти ограничения UML в 2006-2011 гг. архитектор ПО Саймон Брауном предложил модель описания архитектуры C4, основанную на некоторых идеях UML и ранее существовавшей модели архитектурного представления 4+1.

Название C4 обусловлено сочетанием 4-х уровней (Context, Container, Component, Code) для моделирования архитектуры, начиная с контекста программной системы до кода через контейнеры и входящие в них компоненты. В отличие от UML, модель C4 не имеет строгих правил записи для графического изображения различных аспектов моделирования программной архитектуры. Главной идей метода является принцип структурной декомпозиции системы на контейнеры и компоненты с конечным моделированием набора сущностей и связей между ними в виде диаграммы классов UML или ERD.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

TTIS

Ближайшая дата курса

24 июля, 2023

Длительность обучения

12 ак.часов

Стоимость обучения

20 000 руб.

Как уже было отмечено выше, C4 основана на модели 4+1, где комбинируются разные представления системы, важные для различных стейкхолдеров: конечные пользователи, разработчики, системные инженеры (администраторы и DevOps), а также руководители проектов. А +1 означает, что вместе все эти 4 представления (логическое, реализации, физическое и процессное) образуют еще одно – сценарное. Эта модель была предложена Филиппом Кручтеном из компании Rational еще 1995 году и, в отличие от C4, предполагает только объектно-ориентированную парадигму. Поэтому неудивительно, что в качестве иллюстраций для каждого представления программной системы автор предложил использовать именно UML.

Таким образом, представления модели 4+1 отражают практическую последовательность проектирования ПО в UML, которую можно представить в следующей таблице:

Однако, несмотря на детальное описание многих аспектов, инструментарий UML и представления модели 4+1 не охватывают некоторые важные нюансы, например, положение проектируемой системы в корпоративном ИТ-ландшафте. Дополнительным ограничением модели 4+1 является фокус на ООП и использование строгих правил UML-нотаций, что накладывает определенные требования к разработчикам и читателям диаграмм, повышая порог практического использования этого инструментария. Как С4 предлагает обойти эти ограничения, рассмотрим далее.

UML для бизнес-аналитика: основы ООП и разработка моделей

Код курса

BUML

Ближайшая дата курса

10 августа, 2023

Длительность обучения

8 ак.часов

Стоимость обучения

15 000 руб.

Что такое С4 и как ее использовать

Модель C4 описывает архитектуру программных систем, иерархически декомпозируя ее с уровня контекста до контейнеров, их компоненты и внутреннего устройства компонентов на уровне кода. Хотя C4 не навязывает формальных нотаций со строгими правилами записи для построения диаграмм как это есть в IDEF0 или UML, модель предполагает наглядные иллюстрации архитектуры системы с помощью следующих схем:

• диаграммы контекста (Context), которые являются схемами 1-го уровня абстракции и показывают контекстное окружение программной системы, т.е. ключевые ее взаимодействия с акторами – активными сущностями вне системы, которые взаимодействуют с ней, но не являются ее часть. На практике акторами являются пользователи и внешние сервисы. Суть диаграммы контекста в C4 аналогична контекстной диаграмме потоков данных DFD, которая рассматривает систему как черный ящик, куда попадают потоки данных от внешних сущностей и что они получают от системы. UML-диаграмма вариантов использования (use case) верхнего уровня тоже частично раскрывает особенности контекста, однако, она рассматривает проектируемую систему скорее как серый ящик, раскрывая основные возможности, доступные тому или иному актору.

Например, в рамках системы управления оплаты договоров на образовательные курсы, что мы рассматривали здесь и здесь, диаграмма системного контекста C4 может выглядеть так:

А DFD-диаграмма контекстного уровня будет выглядеть таким образом:

Наконец, UML-диаграмму вариантов использования (use case) верхнего уровня можно представить так:

• диаграммы контейнеров (Container) разбивают систему на взаимосвязанные контейнеры – приложения и базы/хранилища данных. Также контейнером в С4 считается файловая система, программный скрипт, бессерверная функция и прочие макро-компоненты, нужные для работы описываемой системы. Суть этой диаграммы аналогична совмещенной UML-диаграмме компонентов и развертывания. Для нашей системы диаграмма контейнеров C4 может выглядеть так:

Совмещенная UML-диаграмма развертывания для системы с классической трехзвенной архитектурой может выглядеть так:

• Диаграммы компонентов (Component): разделяют контейнеры на взаимосвязанные компоненты и отражают их связи с другими контейнерами или системами. Поскольку эта схема составляется для разработчиков, в качестве компонентов в C4 могут быть контроллеры, программные модули и пр. макро-элементы кода. В UML этот уровень может быть отображен диаграммой пакетов или компонентов.
• Диаграммы кода (Code) предоставляют дополнительные сведения о дизайне архитектурных элементов, которые могут быть сопоставлены с программным кодом. Здесь могут быть представлены UML-диаграммы классов или ERD-диаграммы, иллюстрирующие структуру базы данных.

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

Основные схемы модели C4

• компонентов (component)
• развертывания (deployment)

• пакетов (package)
• компонентов (component)

Дополнительные схемы модели C4

Источник: babok-school.ru

Кратко о типах архитектур программного обеспечения и переходе на микросервисы

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

Типы архитектур ПО

Многоуровневая архитектура

Это одна из самых распространенных архитектур. На её основе построено множество крупных фреймворков — Java EE, Drupal, Express. Пожалуй, самый известный пример этой архитектуры — это сетевая модель OSI. Система делится на уровни, каждый из которых взаимодействует лишь с двумя соседними.

Поэтому запросы к БД, которая обычно располагается в самом конце цепочки взаимодействия, проходят последовательно сквозь каждый «слой». Архитектура не подразумевает какое-то обязательное количество уровней — их может быть три, четыре, пять и больше. Чаще всего используют трехзвенные системы: с уровнем представления (клиентом), уровнем логики и уровнем данных. О многоуровневой архитектуре написано бесчисленное количество книг и статей. И сложились разные мнения о ее достоинствах и недостатках.

Плюсы:

Каждый уровень этой архитектуры выполняет строго ограниченный набор функций (которые не повторяются от слоя к слою) и не знает о том, как устроены остальные уровни. Поэтому «содержимое» уровней можно изменять без риска глобальных конфликтов между слоями.В целом многоуровневые приложения настолько распространены, что для их разработки создаются специальные генераторы шаблонов. Например, LASG для Visual Studio предлагает несколько методов генерации кода, которые автоматизируют рутинные задачи и помогают выстраивать уровни приложения.

Недостатки:

В программировании есть присказка, что любую проблему можно решить добавлением еще одного уровня абстракции. Однако такой подход в конечном счете может привести к плохой организации кода и запутать разработчиков.Отсюда вытекает еще одна проблема — низкая скорость работы. Очень много информации начинает бесполезно проходить от слоя к слою, не используя бизнес-логику.

Иногда эту проблему называют sinkhole anti-pattern — шаблон проектирования, когда количество бесполезных операций начинает преобладать над полезными.Поиск багов в многоуровневых системах также может быть затруднен. Прежде чем попасть в базу данных, информация проходит через все уровни (так как БД является конечным компонентом). Если по какой-то причине эта информация повреждается (или теряется по пути), то для поиска ошибки приходится анализировать каждый уровень по отдельности.

Хорошо подходит:

• Для создания новых приложений, которые нужно развернуть по-быстрому. Это своеобразный «шаблон общего назначения».

Когда мы в 1cloud начинали работу над внутренними системами нашего провайдера виртуальной инфраструктуры, то использовали именно этот тип архитектуры. На старте перед нами не стояла задача сделать IaaS-сервис, способный обработать трафик десятков или сотен тысяч пользователей. Мы решили оперативно выпустить продукт на рынок и начать нарабатывать клиентскую базу, а проблемы масштабирования решать по мере их поступления (и сейчас мы переводим все системы на микросервисную архитектуру, о которой далее).

Событийно-ориентированная архитектура

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

Это событие запускает процесс предпродажной подготовки — установку дополнительного оборудования, проверку технического состояния, мойку и др.Система, управляемая событиями, обычно содержит два компонента: источники событий (агенты) и их потребители (стоки). Типов событий обычно тоже два: инициализирующее событие и событие, на которое реагируют потребители.Примером реализации такой архитектуры может служить библиотека Java Swing. Если классу нужно оповещение о каком-либо событии, разработчик реализует так называемого слушателя — ActionListener (он «ловит» соответствующий эвент), и дописывает его к объекту, который это событие может сгенерировать. На Wiki приводится следующий код реализации этого механизма:

Достоинства архитектуры:

Так как приложения состоят из большого количества асинхронных модулей (у которых нет информации о реализации друг друга), их легко масштабировать. Такие системы собираются как конструктор — прописывать зависимости не нужно, достаточно реализовать новый модуль. Дополнительно асинхронная модель позволяет добиться высокой производительности приложений.

Недостатки:

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

Микроядерная архитектура

Этот тип архитектуры состоит из двух компонентов: ядра системы и плагинов. Плагины отвечают за бизнес-логику, а ядро руководит их загрузкой и выгрузкой.

Как пример микроядерной архитектуры в книге O’Reilly приводится Eclipse IDE. Это простой редактор, который открывает файлы, дает их править и запускает фоновые процессы. Но с добавлением плагинов (например, компилятора Java) его функциональность расширяется. Микроядерную архитектуру в свое время использовала операционная система Symbian для мобильных устройств (разработку прекратили в 2012 году). В её микроядре находился планировщик задач, системы управления памятью и драйверы, а файловая система и компоненты, отвечающие за телефонную связь, выступали в роли плагинов.

Достоинства архитектуры:

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

Недостатки:

Производительность приложения снижается, если подключать слишком много модулей. Однако бывает проблематично найти баланс между количеством плагинов и числом задач микроядра (обычно оно содержит лишь часто используемой код).Также сложно определить заранее (до начала разработки приложения) оптимальную степень дробления кода микроядра. А поменять подход позднее практически невозможно.

Хорошо подходит для:

• Создания расширяемых приложений, которыми пользуется большое количество людей. Например, ОС для iPhone имеет «микроядерные» корни — её разработчики черпали вдохновение в Mach (это один из самых первых примеров микроядра).
• Создания приложений с четким разделением базовых методов и высокоуровневых правил.
• Разработки систем с динамически меняющимся набором правил, которые приходится часто обновлять.

Микросервисы

Похожи на архитектуру, управляемую событиями, и микроядро. Но используются тогда, когда отдельные задачи приложения можно легко разделить на небольшие функции — независимые сервисы. Эти сервисы могут быть написаны на разных языках программирования, поскольку общаются друг с другом при помощи REST API (например, с использованием JSON или Thrift).В каких пропорциях делить код, решает разработчик, но Сэм Ньюмен (Sam Newman), автор книги «Создание микросервисов», рекомендует выделять на микросервис столько строк кода, сколько команда сможет воспроизвести за две недели. По его словам, это позволит избежать излишнего «раздувания» архитектуры.Чаще всего микросервисы запускаются в так называемых контейнерах. Эти контейнеры доступны по сети другим микросервисами и приложениям, а управляет ими всеми система оркестровки: примерами могут быть Kubernetes, Docker Swarm и др.

Достоинства:

• В крупных проектах с высокой нагрузкой. Например, микросервисы используются стриминговыми платформами. Системы доставки контента и иные вспомогательные сервисы можно масштабировать независимо друг от друга, подстраиваясь под изменения нагрузки.
• В системах, использующих «разномастные» ресурсы. Если одной части приложения нужно больше процессорного времени, а второй — памяти, то имеет смысл разделить их на микросервисы. После чего их можно захостить на разных машинах — с мощным CPU или большим объемом памяти соответственно.
• Когда нужна безопасность. Так как микросервисы изолированы и общаются по API, можно гарантировать, что передаваться будет только та информация, которая нужна тому или иному сервису. Это важно при работе с паролями или данными платёжных карт.

Почему мы в 1cloud переходим на микросервисы

Как мы уже говорили, в основе предоставляемых нами сервисов (частное облако, виртуальные серверы, объектное облачное хранилище и др.) лежит многоуровневая архитектура. Она показала себя с хорошей стороны, но теперь её возможности по масштабированию начали иссякать.У нас становится все больше партнеров, которые предоставляют свои решения на базе нашей платформы по франшизе.

Появляются удаленные площадки и сервисы, которыми становится сложно управлять из единой точки (в частности, наше оборудование находится в нескольких дата-центрах в России, Казахстане и Беларуси).Чтобы было проще масштабировать существующие функции и внедрять новые фичи, мы в 1cloud переводим всю нашу инфраструктуру на микросервисы.Мы хотим выделить их в отдельные модули и вместо одной сложной базы данных получить N простых. Таким образом, в новой архитектуре каждой фиче будет соответствовать отдельная БД.

Это гораздо удобнее и эффективнее в поддержке и разработке.Мы сможем разделить работу над сервисами между несколькими разработчиками (выделить специализации в компании) и эффективно масштабироваться горизонтально — когда нужно, будем просто подключать новые микросервисы. Наши клиенты тоже получат ряд преимуществ.

Поскольку микросервисы не связаны друг с другом, то при выходе из строя конкретной услуги будет недоступна только она, все остальные продолжат функционировать в штатном режиме. При этом даже если произойдет глобальное падение нашего сервиса, то панель управления продолжит работать.Клиенты из Казахстана и Беларуси (и других стран, где мы откроем представительства) заметят существенное увеличение скорости и отзывчивости интерфейсов, так как панели управления будут размещаться локально.Что уже сделано. Пока мы реализовали только первый пилот: «Услугу Мониторинг». Остальные сервисы переведем на новые рельсы в конце 2018 — начале 2019 года.При этом новая архитектура закладывает технологическую основу для следующего этапа — миграции на контейнеры. Сейчас мы используем Windows-инфраструктуру, и для перехода в контейнеры нужно переписать весь накопившийся код на .NetCore и перевести его под управление Linux.Начать новый переход планируем в начале 2019 года и закончить его в конце следующего года.

Простыми словами о том, что стоит запомнить про архитектуры

• Эволюция архитектуры облака 1cloud: сложности модулирования
• Как IaaS помогает франчайзи «1С»: опыт 1cloud
• Зачем нужен мониторинг?

Источник: spark.ru