В SDLC (който според мен е непълен като понятие, но това е друга тема) особено интересен е проблема със скалирането на приложения. От една страна, монолитната архитектура е по-удобна за разработка по ред причини, от друга - разпределената е по-добра за скалиране. Тук идва интересната част - обикновено проектите се задават с определен срок на изпълнение, съответно:

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

- и да се наложи, голямо е изкушението да се направи проекта в срок, съответно скалирането да се отложи за по-натам

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

Като цяло ми е интересно дали някой се е сблъсквал с подобни проблеми и какви решения е виждал.

Ами то за да прецениш точно трябва да знаеш бъдещето. Което очевидно е невъзможно. Тоест винаги е вид прогноза и залагане.

Но от друга страна, защо тази дихотомия? Монолитният проект също може да се скалира, ако е подходящо проектиран. Ето примерно AsmBB е абсолютен монолит, но позволява скалиране. Не до безкрайност, но все пак доста.

Всяко проектиране лежи в бъдещето, т.е. винаги има определена доза неопределеност

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

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

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

Според мен това със скалирането е по-скоро икономически проблем,а не толкова технологичен,аз бих го проектирал така както пише в бизнес плана

Golden Gega

В крайна сметка идва момент, аз съм стигал до такъв, че оптимален вариант е да се почне с монолитна структура заради по-ниската цена на изработка и преминаване към разпределена за по-лесно и по-точно (т.е. оптимално като цена) скалиране.

Струва ми се, че при правилно проектиране, в монолита следва да се оставя "перфорация" за по-лесно разделяне при преминаването към разпределена архитектура.

В смисъл, струва ми се, че всеки монолит може да се проектира така, че преминаването към разпределена структура да бъде максимално лесно и плавно.

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

@saruman - именно, то е икономически проблем. Проблема е когато в бизнес плана пише например че имаш за изработка 12 месеца (недостатъчни за разпределена архитектура, особено ако домейна е непознат, заданието е мъгляво, например ако имаш да прави проект по уникална бизнес дейност), че на 3-тия месец имаш 5 000 клиента, на 6-тия - 20 000, на 12-тия - 140 000. Т.е. се налага да скалираш почти в движение.

@jhonfound - перфорацията ми хареса като термиц И да, точно такова решение съм предлагал - сегментиране на логиката и сегментиране на данните с монолитна архитектура, т.е. преминаване към микросървисна архитектура в движение.

Отписа ми се, но да уважа гегата и единствената сериозна тема за денят.

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

Чудесно, ама бюджета биеше натам - около 400-500к в зелено. А всеки такъв проект, ако е успешен разбира се, е ценен за софтуерната фирма, заради поддръжката. Ако продукта е добър, то с времето той става по-добър, съответно поддръжката по-евтина, а при добър търговски отдел - печалбата се вдига.

Golden Gega

че на 3-тия месец имаш 5 000 клиента, на 6-тия - 20 000, на 12-тия - 140 000

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

saruman

Golden Gega

че на 3-тия месец имаш 5 000 клиента, на 6-тия - 20 000, на 12-тия - 140 000

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

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

То нали се сещаш че човек прави компромис в два случая - ако не знае какво прави и ако го натикат в кофти ситуация.

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

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

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

П.П. Досега май рядко ми се е случвало да познавам бъдещето за което съм усложнявал кода си.

_|_

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

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

П.П. Досега май рядко ми се е случвало да познавам бъдещето за което съм усложнявал кода си.

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

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

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

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

Ако ви трябват опашки, има няколко, но не препоръчвам azure service bus, спрямо rabbitmq е мегаорязан и в същото време не толкова прост. За IoT може и да свърши работа, но за по- сложни сценарии не. Рилея им е хубав, ако имате легаси SOAP. Поддържа си и Gateway с добавена функционалност, Azure API Management. В този ред на мисли има и mssql, postgres, mariadb и други as a service с лесен мениджмънт. Редиси, монгота, рокетдб, всичко as a service. Живеем само с 2 админа, откъм администрация ни е спестил много.

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

Golden Gega

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

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

Golden Gega

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

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

_|_

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

Виждал съм апове, но замислени от добри архитекти, да карат по 10-15 години Рекорда е един C++ socket service, писан е накъде 95-та, още работи, само малко сме добавили функционалност. Поддържа заявките на държавни институции, адвокати и т.н. юридически прищевки на средна скандинавска държава. Стейтлес е, ако се наложи, предполагам лесно ще пусна няколко инстанции и ще го балансирам отпред.

Golden Gega

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

Щото си е патил. Програмистите са като майсторите. Винаги може да си намериш някакъв програмист да ти вземе парите. А добрите са заети и струват скъпо. Правя ремонт вече 9 месеца, разбрах много добре защо хората не харесват майсторите и защо хората не харесват програмистите (тук не включвам обикновените хейтъри). А добър майстор взима пари. За банята хвърлих 12 бона, он взе чиста пара 3 бона за 2 седмици работа :/ Ако набара и друг като мен за още 2 седмици, взима колко мене. А имам и пресен пример с програмисти, на един познат маркетолог клиента е зарязан от погромиста си, няма сорсове, няма пароли, нищо няма, чак на амазон съпорта търсихме. Яката работа. Клиентът му откъде да знае, че сорса си е негов и да си го е искал

Ок, това с микросървисите е подход, но ми е интересно каква ви е схемата на работа - сам проектираш и сам пишеш, проектираш и други пишат, проектираш и пишеш съвместно с другите, проектираш и правиш основите - да кажем база, интерфейси и т.н.?

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

На теория имам архитект, но на практика правя всичко от бази до деплоймънт . Гласувал ми бил доверие, той само ходи се занимава с вендорите. Даже на 2-ма джуниъра сме гласували доверие да си мажат както искат, само им гледам пул рекуестите, че например правят bool TryParseAlabala(object obj, ref Ala ala, ref Bala bala, ref Rev rev). В началото само един ден кое как грубо, после те си пишат. Имаме и един мид, той си прави каквото иска, гласували сме му повече доверие, като не го е направил си го оправя. Общо взето е анархия. Има си предимства, има недостатъци, но го предпочитам пред големите аутсорс компании. Преди бях по- строг, обаче не вървеше работата, защото съм връщал по 10-на пъти пул рекуести и повече се иска да работи, отколкото да се следват практики и т.н., а и ми костваше емоционално напрежение, накрая ги приех зен нещата. В края на краищата, като излезна отпуска не могат да се оправят без мен, което си е джоб секюрити.

Пък микросървисите имам предимството, че е сравнително малко код и нема ко толкова да оакат. Мемори лийк не съм виждал от 3 години, откакто имахме един "специалист" на 23, къде много ги разбираше нещата. Бъгове има от време на време по бизнеса, защото те нямат навика да мислят всички вероятности. Чакат стринг с телефонен номер, каквот толкова може да се обърка? Не е като някой да напише qwerty вместо телефон.... а, всъщност някой го бил написал. Откъм работа с база предпочитам ADO.NET, досега не са забравяли да параметеризират. Имаме и малко entity framework. Накрая си правят сами SonarQube, аз или мида гледаме за груби грешки и кот такоа.

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

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

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

Като цяло архитектурирането е интересна професия, и според мен често пъти криво разбрана като цел. Всъщност малко бягам от темата, но принципно е трудно да се намерят хора с които да се говори (ползотворно и приятно) в тия неща.

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

Колкото за скалирането - Джони много точно определи прехода от монолитна към разпределена архитектура с "перфорация". Поне при мен това означава че продукта се изгражда като монолитен (от страна на BA/програмисти) и като перфориран (аз използвам термина филетиран), т.е. подготвен за разпределение от архитектурна гледна точка. От гледна точна на една функционалност - да кажем на продажби - това означава да се постави на критичното място имплементация, която се реализира като монолит докато мине алфа версията например, т.е. докато се изчисти в огромна степен логиката и интегритета с други модули. И когато стане нужда да се скалира, да може да се направи в движение, с предварително известен миграционен план за разделяне на данните в жива база и т.н. и т.н.

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

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

Golden Gega

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

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

А изтрий го сега, нали се натискаш за брадвичка!