Шкільне харчування є важливою складою навчального процесу, тому важливозабезпечити правильне та збалансованне меню для закладів освіти. Наявність такогоменю дозволить покращити якість шкільного харчування, що в свою чергу покращитьсам навчальний процес.Основними завданнями системи є надання інструментарію для дієтологів,технологів, кухарів та економістів, що допоможе створити якісне меню при цьомузалишивши приємливу ціну на страви для школярів.Для зручної роботи всіх діючих осіб потрібно розмежувати функціонал, надаючикожній з діючих осіб лише ті функції, які вони будуть використовувати. При цьомупотрібно зберегти гнучкість системи, для комфортної підтримки та її розширення занеобхідності. Для цього, окрім написання хорошого людино-орієнтованого коду,потрібно ретельно підійти до вибору архітектури та проектування системи. Щобзабезпечити гнучкість та простоту чудово підійде мікросервісна архітектура.Термін мікросервісна архітектура, також відомий як мікросервіси, з’явився всередині 2010-х, він описує особливий архітектурний стиль розробки програмногозабезпечення. Цей стиль розробки став популярним у зв’язку з розвитком практикгнучкої розробки та DevOps.Архітектурний стиль мікросервісів — це підхід, коли єдиний додаток будується яксукупність невеликих, самодостатніх, не тісно зв’язаних сервісів, які спілкуються задопомогою легких механізмів, як HTTP, gRPC. Ці сервіси побудовані навколо бізнес-потреб (кожен відповідальний за конкретний процес) та розгортаються незалежно одинвід одного. Самі сервіси можуть бути написанні на різних мовах і використовуватирізні технології зберігання даних.Серед основних переваг використання такого підходу, це можливість швидкощось змінювати, адаптувати продукт до нових бізнес-вимог. Розробники можутьшвидко та безпечно вносити зміни до проекту, навіть коли він виростає до величезнихрозмірів.

Для кращого розуміння переваг та недоліків такого підходу його вартопорівняти з альтернативою — монолітним підходом.Моноліт будується як єдине ціле. Будь-які зміни, навіть невеликі, потребуютьперебудови та розгортання вього додатку. З часом такий додаток розростається доколосальних розмірів, стає проблематично зберігати модульну структуру, зміни водних модулях часто впливають на роботу інших, появляється проблема з дебагомдодатку та його подальшим розвитком та підтримкою. В результаті використаннятакого підходу для маштабних проектів приводить до зростання вартості розробки,зміни в проекті можуть приводити до величезної кількості багів, весь процес розробкибуде виглядати як черговий білд додатку, який може тривати десятки годин. Проте навідміну від мікросервісів менеджмент проекту, що базується на монолітній архітектуріє набагато дешевшим та простішим, а всі недоліки є неважливими якщо розмірипроекту є не великими і він не буде кардинально змінюватись чи розширюватись.Мікросервіси в свою чергу на противагу моноліту розгортаються кожнийокремо, тому якщо в одному з мікросервісів відбуваються зміни, то можна розгорнутиці зміни не чіпаючи інших мікросервісів, які будуть продовжувати працювати.Недоліки мікросервісів: транзакції між мікросервісами не безплатні: оскільки мікросервіси це окреміневеликі додатки, які розгортаються на різних машинах для взаємодії вонивикористовують мережу, що призводить до затримок; формат повідомлень: мікросервіси вимагаються стандартизіції та узгодженняформатів повідомлень, відсутність цього призводить до виникнення помилок таскладнощів налагодження; балансування та відмостійкість: не всі сервіси матимуть однакове навантаженнятому потрібно балансувати їх (розгортати декілька інстансів, виділяти бульшересурісів), критично важливі сервіси потрібно захищати від відмови(відмовостійкі контейнери); складність тестування: у випадку з unit-тестуванням мікросервіси виграють,оскільки їх кількість буде розмежована між сервісами та не займатиме багаточасу, проте при розгортанні системи потрібно переконатися у звʼязку з рештоюсервісів, а також з базами даних, оскільки їх може бути не одна; складність операційної підтримки: використання мікросервісів потребуєнаявніть кількох DevOps-інженерів, оскільки при роботі відбуваєтьсябезперервне розгортання та моніторинг інстансів.Переваги мікросервісів: сервіси є невеликими і запускаються набагато швидше, що робить розробкунабагато ефективнішою; сервіси маштабуються окремо; кожен сервіс розгортається окремо; якщо в одному мікросервісі виникає баг він не матиме великого впливу на інші,а завдяки детальному логуваню та невеликим розмірам, пошук та виправленнятакого багу займає менше часу; мікросервіси краще організованні, оскільки кожен з них має свою специфічнуроботу і не виконує роботу інших сервісів; відсутність привʼязки до стеку технологій, кожний сервіс у системі можназамінити. Кожен сервіс можна переписати з нуля без необхідностіперебудовувати всю систему.Отже, використання мікросервісів допомагає краще організувати структурупроекту та зберегти гнучкість на пізніх етапах розробки. Оскільки кожний сервіс цеокремий додаток, використання гнучких методологій стає простішим, один сервіс —один цикл. Серед недоліків підвищена вартість підтримки робочих інстансів, проте вдовгостроковій перспективі це окупиться.