Startupe, Da li zaista želite da platite porez na microservices?

Зашто раскидање ваше базе кода прерано може тихо уништити брзину вашег тима - и шта да радите уместо тога.

Зашто раскидање ваше кодне базе прерано може тихо уништити брзину вашег тима - и шта да радите уместо тога.

у једном старту,your survival depends on how quickly you can iterate, ship features, and deliver value to end-usersОво је место где основна архитектура вашег стартапа игра велику улогу; Поред тога, ствари као што су ваш технолошки стек и избор програмског језика директно утичу на брзину вашег тима.

Имао сам ово искуство када радим на пројектима зеленог поља за почетне стартапе, где су донете сумњиве одлуке у смислу софтверске архитектуре која је довела до полу-завршених услуга икрхке, прекомерно инжењерисане и сломљене локалне поставке, иdemoralized teamsкоји се боре за одржавање непотребне сложености.

Пре него што уроните у одређене замке, ево шта се заправо пријављујете приликом преурањеног увођења микро-услуга:

Microservices Early On: What You’re Paying For

Комплексност распореда

Оркестрирање 5+ услуга за једну функцију

Hours lost per release

Локални Дев Фрагилитет

Доцкер шири, сломљене скрипте, хакови специфични за платформу

Slow onboarding, frequent breakage

ЦИ / ЦД дуплирање

Више цевовода са дуплираном логиком

Extra toil per service

Цросс Сервице Цопулинг

"Откључане" услуге које су чврсто повезане заједничком државом

Slower changes, coordination tax

Опште посматрање

Дистрибуирано праћење, логирање, праћење

Weeks to instrument properly

Тест Suite Фрагментација

Тестови разбацани преко услуга

Brittle tests, low confidence

Хајде да размотримо зашто се микро-услуге често враћају рано, где заиста помажу и како структурирати системе вашег стартупа за брзину и преживљавање.

Monoliti nisu neprijatelj

Ако градите неки СааС производ, чак и једноставан СКЛ база података омотач на крају може донети много интерне сложености у начину на који функционише ваша пословна логика; Поред тога, можете доћи до различитих интеграција и позадинских задатака који омогућавају трансформацију једног скупа података у други.

Временом, понекад непотребне функције, неизбежно је да ваша апликација може постати неред.Monoliths, even when messy, keep your team focused on what matters most:

• Ostati živ
• Pružanje korisničke vrednosti

Највећа предност монолита је њихова једноставност у распореду. Генерално, такви пројекти су изграђени око постојећих оквира - то би могао бити Дјанго за Пајтон,АСП.нетza C#, Nest.js za Node.js aplikacije, itd. Kada se držite monolitne arhitekture, dobijate najveću prednost u odnosu na fancy microservices – široku podršku otvorenog koda zajednice i projektnih menadžera koji su prvenstveno dizajnirali te okvire da rade kao jedan proces, monolitna aplikacija.

На једном стартапу за некретнине где сам водио фронт-енд тим, а повремено сам се консултовао са бацкенд тимом о технолошким изборима, имали смо занимљиву еволуцију апликације засноване на Ларавелу.

Временом се развио у пакет богатих функцијама који је управљао стотинама гигабајта докумената и интегрисао се са десетинама услуга треће стране.

Тим се у великој мери ослањао на најбоље праксе које препоручује заједница Ларавела. Та дисциплина се исплатила, могли смо значајно проширити могућности апликације док и даље задовољавамо потребе и очекивања пословања.

Занимљиво је да никада нисмо морали да раздвојимо систем у микро-услуге или да усвојимо сложеније обрасце инфраструктуре. Избегли смо пуно случајне сложености на тај начин. Једноставност архитектуре нам је дала оптерећење.„Велики монолит“, што објашњава зашто је једноставност рано суперсила.

Људи често указују да је тешко направити монолите скалабилне, али то је лоша модуларизацијаunutraмонолит који може довести до таквих проблема.

Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting.

Али, зар микро-услуге нису „најбоља пракса“?

Mnogi inženjeri se ranije približavaju mikroslužbama, misleći da su „na pravom putu.“ I sigurno – u skali, oni mogu da pomognu.

Микро-услуге се исплаћују само када имате стварне препреке за скалирање, велике тимове или независно развијају домене. Пре тога? Плаћате цену без добијања користи: дуплиране инфра, крхке локалне поставке и споро итерирање.SegmentНа крајуПовратак њиховог микросервисаiz tog tačnog razloga – previše troškova, nedovoljna vrednost.

Takeaway: Microservices are a scaling tool — not a starting template.

Где микро-услуге иду погрешно (посебно рано)

У једној екипи у раној фази коју сам саветовао, одлука да се поделе услуге створила је више ПМ-инжењерске координације у односу на техничку добит.Архитектура није обликовала само код, већ како смо планирали, проценили и испоручили.

Ево најчешћих анти-модела који се појављују рано.

1. произвољне границе услуге

У теорији, често видите сугестије о раздвајању ваших апликација по домену пословне логике - кориснички сервис, сервис производа, сервис наруџбине, итд. Ово се често позајмљује од концепта Дизајн на домену или Чиста архитектура - који имају смисла у скали, али у раним фазама производа, они могу прерано оссификовати структуру, пре него што сам производ буде стабилан или валидиран.

• Заједничке базе података
• Cross-Service zahteva jednostavne tokove posla
• Удружење прекривено као "сепарација"

На једном пројекту, видео сам тим који је одвојио корисника, аутентификацију и овлашћење у одвојене услуге, што је довело до сложености распореда и потешкоћа у координацији услуга за било коју операцију АПИ-а коју су изградили.

У стварности, пословна логика не директно мапира границе услуга. прерано одвајање може учинити систем крхким и често је тешко брзо увести промене.

Уместо тога, изолујте бочице хируршки - на основу стварног скалирања бола, а не теоријске елеганције.

Када сам тренирао тимове у раној фази, понекад смо користили интерне заставе или прекидаче за распоређивање како бисмо симулирали будуће сервисне поделе - без непосредног оперативног оптерећења.

Takeaway: Don’t split by theory — split by actual bottlenecks.

Репозиторијум и инфраструктура Sprawl

Приликом рада на апликацији, обично је важан следећи скуп ствари:

• Конзистентност стила кода (линтинг)
• Тестирање инфраструктуре, укључујући тестирање интеграције
• Локална конфигурација окружења
• Документација
• ЦИ / ЦД конфигурација

Ако је ваш пројекат структуриран као монорепо, можете поједноставити свој живот тако што ћете имати централну ЦИ / ЦД конфигурацију (када радите са ГитХуб Ацтионс или ГитЛаб ЦИ).

За тим од три особе, ово је брутално. пребацивање контекста између репозиторија и алатки додаје време развоја сваке функције која се испоручује.

Ублажавање проблема користећи монорепос и један програмски језик

Постоје различити начини за ублажавање овог проблема.За ране пројекте, једина најважнија ствар је - чување вашег кода у монорепо. Ово осигурава да постоји једна верзија кода која постоји на проду, и много је лакше координирати прегледе кода и сарађивати за мање тимове.

Za Node.js projekte, snažno preporučujem korišćenje monorepo alata kao što jenxилиturborepoОбојица су:

• Поједноставите ЦИ / ЦД конфигурацију преко подпројеката
• Podrška zavisnosti Graph-based build caching
• Нека се интерне услуге третирају као библиотеке ТипСцрипта (преко увозних ES6)

Ови алати штеде време у супротном потрошено на писање лепљивог кода или реинвентирање оркестрације.

• Kompleksno zavisno drvo može brzo da raste
• Туннинг перформанси ЦИ није тривијалан
• Можда ће вам требати брже алатирање (као што је бун) да бисте задржали време изградње

Да бисмо резимирали: Tooling likenxилиturborepoдаје малим тимовима монорепо брзину - ако сте спремни да инвестирате у одржавање чистоће.

Kada se razvijago- микро-услуге, добра идеја на почетку развоја је да се користи један goРадни простор саreplaceДиректива уgo.modНа крају, како софтвер скалира, могуће је без напора раздвојити goМодули у одвојеним складиштима.

Takeaway: A monorepo with shared infra buys you time, consistency, and sanity.

Broken Local Dev = прекинута брзина

If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity.

Рани пројекти често пате од:

• Недостаје документација
• застареле зависности
• ОС-специфични хакови (здраво, само Линук подешавања)

Po mom iskustvu, kada sam dobijao projekte od prethodnih timova za razvoj, oni su često bili razvijeni za jedan operativni sistem. Neki programeri su radije gradili na macOS-u i nikada se nisu brinuli da podržavaju svoje skripte za shell na Windows-u. U mojim prethodnim timovima, imao sam inženjere koji su radili na Windows mašinama, a često je bilo potrebno prepisivanje skripta za shell ili potpuno razumevanje i obrnuto inženjering procesa za pokretanje lokalnog okruženja. S vremenom smo standardizovali podešavanje okruženja preko dev OS-a kako bismo smanjili trenje na brodu – mala investicija koja je uštedela satove po novom inženjeru.

У другом пројекту, соло девелоп је створио крхку микросервисну конфигурацију, да је ток рада за покретање Доцкер контејнера монтиран на локални датотечни систем.

Али уградња новог фронт-енд програмера са старијим Виндовс лаптопом претворила се у ноћну мора. Морали су да пребаце десет контејнера само да би видели УИ. Све је прекинуто - запремине, мреже, компатибилност контејнера - и подешавање је веома слабо документовано.

На крају смо хаковали Node.js прокси који је имитирао конфигурацију нгинк / Доцкер без контејнера.То није било елегантно, али је омогућило програмеру да се одблокира и почне да доприноси.

Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster.

Tip:Idealno, cilj jegit clone <repo> && make upАко то није могуће, онда одржавање ажуриране РЕАДМЕ датотеке са упутствима за Виндовс / мацОС / Линук је неопходно. Данас, постоје неки програмски језици и алатки који не раде добро на Виндовсу (као што је ОЦамл), али савремени популарни стек ради добро на сваком широко коришћеном оперативном систему; ограничавањем ваше локалне инсталације на један оперативни систем, то је често симптом недовољног улагања у ДКС.

Технологија Неусклађеност

Поред архитектуре, ваш технолошки стек такође обликује како болне микро-услуге постају - не сви језици сијају у архитектури микро-услуга.

• Node.js i Python: Odlično za brzu iteraciju, ali upravljanje izgradnjom artefakata, zavisnim verzijama i doslednošću u radnom vremenu preko usluga postaje bolno brzo.
• Иди: Компилује се у статичке бинаре, брзо време изградње и ниско оперативно оптерећење.

Ако тражите перформансе, можда тражите ЈВМ и његов екосистем и способност да распоредите артефакте на скали и покренете их у архитектурама заснованим на микро-услугама.

Врло често тимови схватају да постоје велики проблеми са њиховим избором технологије који у почетку нису били очигледни, и морали су да плате цену реконструкције позадине на другом програмском језику (као што јеOvi momciсу били приморани да ураде нешто о наследној бази кода Питхон 2 и мигрирали у Го).

Али напротив, ако вам заиста треба, можете прећи на више програмских језика са протоколима као што суgRPCили асинк комуникација порука. И то је често начин да се о стварима. Када дођете до тачке да желите да обогатите свој опсег функција са функцијама машинског учења или ЕТЛ-овим пословима, само бисте одвојено изградили своју МЛ-ову инфраструктуру у Питону, због свог богатог екосистема домена специфичних библиотека, које природно нема било који други програмски језик. Али такве одлуке треба донети када има довољно главног рачуна да оправда овај подухват; иначе ће мали тим заувек бити увучен у бескрајну сложеност удруживања више софтверских стекова.

Takeaway: Match the tech to your constraints, not your ambition.

Скривена сложеност: комуникација и надзор

Микро-услуге уводе невидљиву мрежу потреба:

• Службена открића
• API верзија
• Ретрије, прекидачи кола, падавине
• Дистрибуирани трацкинг
• Централизовано логирање и упозорење

У монолиту, грешка може бити једноставна стацк стацк траце. У дистрибуираном систему, то је "зашто услуга А не успије када Б-ова имплементација заостаје Ц за 30 секунди?" Морали бисте темељито уложити у свој стацк посматрања. Да бисте то урадили "правилно", потребно је инструментисати своје апликације на одређене начине, на пример, интегрисати ОпенТелеметрију да подржи праћење, или се ослањати на алате вашег провајдера облака као што је АВС КСРАИ ако идете са сложеним сервером. Али у овом тренутку, морате потпуно пребацити свој фокус са апликационог кода на изградњу сложене инфраструктуре за праћењеactuallyфункционисање у производњи.

Наравно, неки од инструментације посматрања треба да се обављају на монолитним апликацијама, али то је много једноставније него то у смислу броја услуга на доследан начин.

Tip:Razumite todistributed systems Nisu slobodni.Они су посвећеност потпуно новој класи инжењерских изазова.

Када микроорганизмидоImajte smisla

Упркос поменутим потешкоћама са микро-услугама, постоје времена када је одвајање на нивоу услуге заправо веома корисно.

• Изолација радног оптерећења: уобичајени пример за то би био у АВС најбољим праксама о коришћењу обавештења о догађајима С3 - када се слика учитава у С3, изазива процес промене слике / ОЦР, итд Зашто је корисно: можемо одвојити нејасне библиотеке за обраду података у самоизоловану услугу и учинити га АПИ фокусиран искључиво на обраду слике и генерисање излаза из учитаних података.
• Потребе за дивергентном скалабилности: — Замислите да градите АИ производ. Један део система (веб АПИ) који покреће МЛ радне оптерећења и показује прошле резултате није ресурс интензиван, то је лагано, јер углавном комуницира са базом података. Напротив, МЛ модел ради на ГПУ-има је заправо тежак за покретање и захтева посебне машине са ГПУ подршком са додатном конфигурацијом.
• Различити захтеви за покретање: — Претпоставимо да имате неки наследни део кода написаног у Ц++. Имате 2 избора — магично га претворите у свој основни програмски језик или наћи начине да га интегришете са бази кода. У зависности од сложености те наследне апликације, можда ћете морати да напишете лепљиви код, имплементирајући додатне мреже / протоколе како бисте успоставили интеракције са том услугом, али суштина је — вероватно ћете морати да одвојите ову апликацију као посебну услугу због некомпатибилности у времену покретања.

Велике инжењерске организације су се бориле са сличним изазовима. На пример, инжењерски тим Уберадокументовани њихов прелазак на домен-оријентисану микросервисну архитектуру— не из теоријске чистоће, већ у одговору на стварну сложеност у тимовима и скалирање граница. Њихов пост је добар пример како микро-услуге могу да раде када имате организациону зрелост и оперативну оверхеад да их подржи.

На једном пројекту, који се такође дешава да је некретнина, имали смо код из претходног тима који покреће аналитичке радне оптерећења засноване на Питону које учитавају податке у МС-СКЛ дБ, открили смо да би било губитак да изградимо на њему апликацију Дјанго.

Takeaway: Use microservices when workloads diverge — not just because they sound clean.

Praktični saveti za startupe

Ако шаљете свој први производ, ево играчке коју бих препоручио:

• Почните монолитно. Изаберите заједнички оквир и фокусирајте се на постизање функција. Сви познати оквири су више него довољно добри да бисте изградили неки АПИ или веб сајт и служили корисницима. Не пратите хипе, држите се досадног начина да радите ствари; можете се захвалити касније.
• Jedno repo. Ne brinite o podeli koda na više repozitorija. Radila sam sa osnivačima koji su želeli da odvojite repo kako bi smanjili rizik od izvoznika koji kopiraju IP – to je važna zabrinutost. Ali u praksi, to je dodalo više trenja nego bezbednosti: sporije konstrukcije, fragmentirane CI/CD i loša vidljivost u timovima. Marginalna IP zaštita nije bila vredna operativnog povlačenja, pogotovo kada su pravilne kontrole pristupa unutar monorepo bile lakše upravljane.
• Dead-simple local setup. Make up work. If it takes more, be very specific on the steps, record a video/Loom, and add screenshots. If your code is going to be run by an intern or junior developer, they will likely hit a road block, and you will spend time explaining how to troubleshoot a problem. Ја сам открио да документовање сваког могућег проблема за сваки оперативни систем елиминише време проведено разјашњавајући зашто одређене ствари у локалном подешавању нису радиле.
• Чак и ако је то једноставан ХТМЛ који можете само ручно сцп на сервер, можете аутоматизовати ово и ослањати се на контролу извора са ЦИ / ЦД-ом да бисте то урадили.Када је подешавање правилно аутоматизовано, једноставно заборавите на своју инфраструктуру континуиране интеграције и фокусирајте се на карактеристике.Видио сам многе тимове и осниваче када раде са аутсорсинг тимовима често су јефтини на ЦИ / ЦД-у, а то резултира тим деморализованим и узнемиреним ручним процесима распореда.
• Сплит хируршки. Сплит само када јасно решава болну бочицу. У супротном, инвестирајте у модуларност и тестове унутар монолита - брже је и лакше одржавати.

И изнад свега:optimize for developer velocity.

Velocity is your startup’s oxygen.Превремене микро-услуге полако цуре тај кисеоник - све док једног дана не можете да дишете.

Takeaway: Start simple, stay pragmatic, and split only when you must.

Ако идете са приступом заснованим на микро-услугама

Имао сам пројекте засноване на микро-услугама креиране раније него што би требало да буду урађене, а ево следећих препорука које бих могао дати о томе:

• Оцените свој технички стек који снабдева вашу архитектуру засновану на микро-услугама. Инвестирајте у алатке за искуство програмера. Када имате одвајање засновано на услугама, сада морате размишљати о аутоматизацији вашег стека микро-услуга, аутоматизацији конфигурације у локалном и производном окружењу. У неким пројектима, морао сам да изградим посебан ЦЛИ који обавља административне задатке на монорепоситоријуму. Један пројекат који сам имао садржао је 15-20 распореда микро-услуга, а за локално окружење, морао сам да креирам кли-инструмент за генерисање докер-компосе.имл датотека динамички до беспрекорно поновно покретање
• Фокусирајте се на поуздане протоколе комуникације око комуникације у служби. Ако је асинхронизирана порука, уверите се да су шеме порука конзистентне и стандардизоване. Ако је РЕСТ, фокусирајте се на документацију ОпенАПИ. Клијенти за комуникацију између услуга морају имплементирати многе ствари које не долазе из кутије: ретриес са експоненцијалним повратком, временским прекидима. Типичан клијент гРПЦ са голим костима захтева да ручно факторирате те додатне ствари како бисте били сигурни да не патите од пролазних грешака.
• Побрините се да је ваш уређај, тестирање интеграције и подешавање тестирања од краја до краја стабилно и скалира са количином раздвајања на нивоу услуге које уносите у вашу базу кода.
• На мањим пројектима који користе радне оптерећења засноване на микро-услугама, вероватно бисте подразумевано користили заједничку библиотеку са заједничким помагачима за инструментализацију ваше посматрања, кода комуникације на доследан начин.
• Додајте структуриране ЈСОН дневнике и креирајте различите ИД-ове за корелацију за дебугирање ствари након што се ваша апликација распореди.Чак и основни помагачи који излазе богате информације о дневнику (док не инструментирате своју апликацију са одговарајућим објектима за дневник / праћење) често штеде вријеме откривајући лажне корисничке токове.

Ukratko: ako još uvek idete za microservices, trebalo bi unapred da razumete porez koji ćete platiti u smislu dodatnog vremena razvoja i održavanja kako bi podešavanje bilo radno za svakog inženjera u vašem timu.

Takeaway: If you embrace complexity, invest fully in making it manageable.

Закључак

Premature microservices are a tax you can’t afford. Stay simple. Stay alive.Раздвојите се само када је бол очигледан.

Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add.

Релевантни ресурси

• Монолит први - Мартин Фаулер
• Величанствени монолит - DHH / Basecamp
• Збогом Мицросервицес: Од 100с проблематичне деце до 1 суперзвезда — сегмент Енг.
• Деконструисање Монолита — Схопифи Енг.
• Domain-Oriented Microservice Architecture — Uber Eng.
• Go + Services = One Goliath Project — Khan Academy (на језику: енглески)