Монолитни срещу микроуслуги и всичко между тях

Монолитни срещу микроуслуги и всичко между тях

Демистифициране на дилемата синьо срещу червено хапче

Разработчиците често решават дали да изградят монолитни или микросервизни архитектуривъз основа на лични предпочитания. Тази статия ви казва как да проектирате най-добрата платформа за вашия клиент, като вземете предвид и двата метода.

Монолитните изцяло свързани платформи могат да обслужват нуждите на стартъпа, но често имат проблеми с мащабирането, за да поддържат растежа. Архитектурите, изградени с модулни микроуслуги, работят добре за по-големи предприятия, но те може да са прекомерно проектирани, за да изискват повече ресурси, отколкото един стартиращ бизнес може да отдели. Тази статия обяснява как да включите и двата подхода за изграждане, за да проектирате функционална стратегия от самото начало, която се развива, за да пасне на всяка точка от жизнения цикъл на проекта.

Тази тема насърчава всякакви дискусии. По някаква причина както микроуслугата, така и монолитният подход генерират фанатични поклонници. Безсмислени дискусии без солидни аргументи често се случват, когато дизайнерите имат силни чувства към архитектурния метод, който предпочитат.

Проблеми, които убиват бизнеса

За да бъде ясно, монолитните архитектури са страхотни. Също и микроуслугите. Но всеки подход служи на конкретна цел в конкретен момент от графика на даден проект. Проблеми възникват, когато извършите един от тези двама най-големи бизнес убийци:

• Прекомерно инженерство. Ако прекомерно проектирате платформа с повече компоненти, отколкото са ѝ необходими на всеки етап от разработката, вие създавате дефектна, тромава структура. Прекомерното инженерство може да причини сериозен технически дълг по-късно, когато вашият продукт се срине и трябва да бъде ремонтиран или напълно преработен.
• Липса на планиране. Ако продължите напред и започнете да кодирате без план, вие пропускате важна и критична стъпка в дизайна. Не приемайте, че вашият любим тип компилация ще отговаря на всички нужди на вашите клиенти във всеки момент от техния цикъл на растеж.

Всички проекти са уникални и всички бизнес цели са различни. Трябва да планираме най-добрия подход от самото начало в сътрудничество с нашия клиент като партньор. След това трябва да коригираме нашия подход, докато проектът се развива. Трябва да работим гъвкаво. Тази статия излага основни знания за монолитите и микроуслугите, разглежда всеки подход и описва хибриден подход. Завършва с препоръки, които се отнасят до някои често срещани проблеми, с които може да се сблъскате.

Монолитният подход

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

Кодът вътре в монолита може да следва софтуерната архитектура и моделите на организация на кода като контролер за изглед на модел (MVC) или модел на изглед на изглед на модел (MVVM). Тези типове приложения се използват най-вече за създаване на минимални жизнеспособни продукти (MVP) или доказателство за концепции. Но след като тези приложения започнат да растат, те обикновено стават по-сложни. Необходим е по-модулен подход, за да бъдат тези платформи устойчиви.

Подходът на микроуслугите

Има много определения за това какво означава архитектура на микроуслуги. Най-много ми харесва

„Специфичен начин за проектиране на софтуерни приложения като пакетиот независимо внедряеми услуги“

- Мартин Фаулър (2014)

Независимо е ключовата дума. Микроуслугите без независими модули са просто хаос. Ако не проектираме независими компоненти, ние създаваме само силно свързан Франкенщайн с ниска кохезия, който изисква много работа за доставяне, работа и поддръжка. По дефиниция архитектурата на микроуслугите има повече слаби връзки и повече ентропия от монолита. Така че се нуждае от повече документация и висококвалифициран екип.

Модулност

Голяма полза от разлагането на приложение на независими по-малки микроуслуги е подобрената модулност. Приложенията за микросервизи са по-лесни за разбиране, разработване и тестване от монолитите. И са по-устойчиви на ерозия на архитектурата.

Рентабилен и мащабируем

По-рентабилно е да мащабирате платформи за микросервизи, защото трябва да мащабирате само отделни компоненти. Не е нужно да правите глобални промени в цяла свързана структура. И е много по-лесно да идентифицирате тесните места, когато можете да наблюдавате всеки компонент поотделно.

По-бързо

Разработката на микросервизи също е по-бърза от монолитната, защото специализирани екипи могат да работят едновременно върху независими части от проекта. Чрез паралелизиране на разработката малките автономни екипи могат да разработват, доставят, изпълняват и мащабират съответните си услуги независимо.

Най-важното нещо за тази диаграма е да се разглежда всяка „услуга“ като отделна единица.

Вашата основна цел при проектиране е всяка услуга да решава всяка бизнес цел по най-оптималния начин. Така че всяка отделна услуга може да се нуждае от NoSQL база данни, Redis кеш или различен език за програмиране от останалите. И услугите за архитектура и внедряване трябва да поддържат всички различни дизайнерски решения. В идеалния случай отделните подсистеми не говорят помежду си, но са хлабаво свързани

Златното правило: можете ли да направите промяна в услуга и да я внедрите сама, без да променяте нищо друго?

― Сам Нюман, „Изграждане на микроуслуги“

Опасностите от свръхинженерството

Има още едно важно нещо, което трябва да се отбележи. Ако вашият екип не може да изгради правилно монолит, той определено не може да изгради архитектура на микроуслуги. Едно от най-лошите неща, които неопитните екипи често правят, е да надмислят проект в началото. Тази грешка на начинаещия може да убие бизнес, защото повечето стартиращи компании нямат пари за изгаряне. Те нямат ресурсите да поддържат излишните компоненти, когато не са необходими, или да плащат за основен ремонт на платформата, за да коригират или премахнат вредните части. Прекомерното инженерство е опасно. Може да изтощи бюджета на компанията, докато не остане нищо, върху което да се работи. Виждал съм много повече компании да се провалят поради свръхинженерство, отколкото поради липса на добра архитектура.

Вземете солидни дизайнерски решения

Лошо проектираната голяма архитектура понякога означава липса на дизайн.

Прекомерното инженерство е знак, че дизайнерският екип не знае как да изгради платформа, която отговаря на нуждите на техния клиент. Понякога екипът на клиента не разбира ясно или не е съгласен със собствените си нужди. Те могат да направят нереалистични предположения за истинския потенциал на своя бизнес. Примамливите фантазии за успех за една нощ могат да доведат до прекъсване на връзката с реалността. Когато екипът на разработчиците и неговият клиент са прекалено уверени или предубедени, има вероятност да вземат погрешни решения въз основа на интуиция, вместо на точни данни. Високофункционален гъвкав дизайнерски екип ще насочва клиентите си в правилната посока и ще работи с тях, за да изгради най-добрата платформа, която да ги отведе там.

Свръхинженерингът обикновено означава твърде много предположения, липса на връзка с реалността, твърде много самоувереност и пристрастия, за да се вземат решения, базирани на интуиция (вместо много по-точни, базирани на данни).

Хибридни подходи

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

Планирайте своята платформа

Дългосрочното планиране ни дава достатъчно информация, за да решим дали да внедрим монолит или да се насочим към по-ориентирана към микроуслуги архитектура. Обикновено не е трудно да се преценят нуждите от мащабируемост. За да може един проект да расте и да успее, той трябва да бъде изграден върху висококачествена платформа, която е проектирана да идентифицира лесно тесните места и да се увеличава стъпка по стъпка.

Модулният монолит

Това, което наричам модулен монолит, е хибридна архитектура, при която платформата не е съставена от множество независими услуги. Но кодът е организиран така, че „семантичните концепции“ да са ясни. С този тип дизайн първо идентифицирате различни, но отделни идеали на високо ниво или групи от функционалности. След това разделяте вашата кодова архитектура, за да отразите това естествено разделение. Архитектура MVC е пример. Можете да разглеждате тази платформа като колекция от MVC подсистеми и можете да отделите кода на всяка подсистема. Промяната на вашата монолитна архитектура на модулен монолит улеснява развитието на платформата. И премахва бариерите пред преобразуването на платформата към микроуслуги, ако са необходими в бъдеще.

Жизненият цикъл на един успешен продукт

Да кажем, че вашата компания преминава от идея за салфетки до бизнес за милиони долари, който стана публичен и че всичко започна с MVP. Вероятно сте започнали с добре проектиран монолит. Вашата компания се опита да идентифицира съответствието на продукта с пазара и взе много решения, базирани на данни. Когато вашият бизнес започна да набира скорост, бяха идентифицирани някои тесни места, реактивно или чрез използване на симулации на тестове за натоварване. Тези болезнени точки изискваха промени в архитектурата, които направиха системата все по-модулна. След още промени някои модули станаха почти независими системи. Екипите могат да работят върху всеки модул поотделно. В същото време DevOps и управлението на внедряването станаха по-сложни, а нивото на автоматизация нарастваше всеки ден. Сега вашият продукт изглежда като подход към микроуслуги, но еволюира до това състояние естествено.

Как повечето компании успяват

• Проектирайте архитектура, която поддържа желаните бизнес резултати.
• Вземете решения, базирани на данни.
• Не прекалявайте с инженерството.
• Предвиждайте предизвикателствата пред скалируемостта и ги планирайте. Бъдете прагматични.
• Избягвайте „решения, водени от егото“ и останете „пъргави“.

За да изградите печеливша платформа, трябва да решите дизайнерските проблеми по най-ефективния и ефикасен начин. Не можете да хабите ресурси с прекалено сложни решения и ненужно свръхинженерство. И трябва да следвате стабилни насоки и стандарти за архитектура, така че платформата да може да се мащабира.

Няма "срещу"

Монолитите са чудесни за някои проблеми, микроуслугите са чудесни за други. Знайте как и кога да адаптирате най-доброто решение или комбинация от решения, за да отговарят на променящите се нужди на вашия проект. Вашата истинска стойност като разработчик е колко добре създавате най-добрите решения за конкретни проблеми.

Знанията за данни, опитът, интуицията, уменията и прагматизмът разделят лошите инженери от добрите и най-добрите – тези, които правят реална разлика в дългосрочния успех на своите клиенти.

Препратки

Conway, M.E. (1968, април). „Как комисиите измислят?“ Взето от http://www.melconway.com/Home/Committees_Paper.html.

Фаулър, М. (2014 г., 25 март). „Микроуслуги: определение на този нов архитектурен термин.“ Взето от https://martinfowler.com/articles/microservices.html.

Фаулър, М. и Уебър, Дж. (2008 г., 6 юни). „Моят автобус голям ли изглежда в това?“ Взето от: https://www.infoq.com/presentations/soa-without-esb/.

Ричардсън, К. (2019). „Какво представляват микроуслугите? Взето от https://microservices.io/.