Хэдийгээр сервергүй технологиуд сүүлийн жилүүдэд хурдацтай дэлгэрч байгаа ч тэдгээртэй холбоотой олон буруу ойлголт, айдас байсаар байна. Борлуулагчийн хамаарал, багаж хэрэгсэл, зардлын удирдлага, хүйтэн эхлэл, хяналт, хөгжүүлэлтийн амьдралын мөчлөг зэрэг нь сервергүй технологитой холбоотой халуун сэдэв юм. Энэ нийтлэлд бид дурдсан сэдвүүдийн заримыг судлахаас гадна эхлэгчдэд хүчирхэг, уян хатан, зардал багатай сервергүй програмуудыг бий болгоход туслах хэрэгтэй мэдээллийн эх сурвалжийн зөвлөмж, холбоосыг хуваалцах болно.
Сервергүй технологийн талаархи буруу ойлголт
Олон хүмүүс сервергүй, сервергүй боловсруулалт хийдэг гэж боддог (, FaaS) нь бараг ижил зүйл юм. Энэ нь ялгаа нь тийм ч их биш бөгөөд шинэлэг зүйлийг нэвтрүүлэх нь зүйтэй гэсэн үг юм. Хэдийгээр AWS Lambda нь сервергүй эрин үеийн оддын нэг бөгөөд сервергүй архитектурын хамгийн алдартай элементүүдийн нэг байсан ч энэ архитектур нь FaaS-ээс хамаагүй илүү юм.
Сервергүй технологиудын үндсэн зарчим бол та дэд бүтцээ удирдах, өргөжүүлэх талаар санаа зовох хэрэггүй бөгөөд зөвхөн ашигласан зүйлийнхээ төлбөрийг төлдөг. AWS DynamoDB, S3, SNS эсвэл SQS, Graphcool, Auth0, Now, Netlify, Firebase болон бусад олон үйлчилгээнүүд эдгээр шалгуурт нийцдэг. Ерөнхийдөө сервергүй гэдэг нь дэд бүтцийг удирдах, өргөтгөхөд оновчтой болгох шаардлагагүйгээр үүлэн тооцооллын бүрэн хүчийг ашиглахыг хэлнэ. Энэ нь дэд бүтцийн түвшний аюулгүй байдал нь таны санаа зовох зүйл байхаа больсон гэсэн үг бөгөөд энэ нь аюулгүй байдлын стандартыг хангахад хүндрэлтэй, төвөгтэй байдаг тул асар их ашиг тус юм. Эцэст нь хэлэхэд, танд өгсөн дэд бүтцийг худалдаж авах шаардлагагүй.
Сервергүйг "сэтгэлийн төлөв" гэж үзэж болно: шийдлийг боловсруулахдаа тодорхой сэтгэлгээ. Аливаа дэд бүтцийн засвар үйлчилгээ шаарддаг арга барилаас зайлсхий. Сервергүй хандлагын тусламжтайгаар бид төсөлд шууд нөлөөлж, хэрэглэгчдэдээ ашиг тусаа өгөх ажлуудыг шийдвэрлэхэд цаг зарцуулдаг: тогтвортой бизнесийн логикийг бий болгож, хэрэглэгчийн интерфэйсийг хөгжүүлж, дасан зохицох чадвартай, найдвартай API хөгжүүлдэг.
Жишээлбэл, хэрэв та үнэгүй текст хайлтын платформыг удирдах, хадгалахаас зайлсхийх боломжтой бол бид үүнийг хийх болно. Аппликейшн бүтээх ийм арга нь зах зээлд гарах хугацааг ихээхэн хурдасгаж чадна, учир нь та нарийн төвөгтэй дэд бүтцийг удирдах талаар бодох шаардлагагүй болсон. Дэд бүтцийн менежментийн хариуцлага, зардлыг хасч, үйлчлүүлэгчдэдээ хэрэгтэй програм, үйлчилгээг бий болгоход анхаарлаа хандуулаарай. Патрик Дебойс энэ аргыг нэрлэсэн , энэ нэр томъёо нь сервергүй нийгэмлэгт батлагдсан. Функцуудыг байршуулах модулиуд (бүхэл бүтэн номын сан эсвэл вэб програмыг ашиглахын оронд) үйлчилгээтэй холбох холбоос гэж үзэх хэрэгтэй. Энэ нь програмын байршуулалт болон өөрчлөлтийг удирдах гайхалтай нарийн ширийн зүйлийг өгдөг. Хэрэв та ийм байдлаар функцуудыг байрлуулж чадахгүй бол энэ нь функцууд хэт олон үүрэг гүйцэтгэдэг бөгөөд дахин засварлах шаардлагатай байгааг илтгэж магадгүй юм.
Зарим нь үүлэн хэрэглээний программуудыг боловсруулахдаа үйлдвэрлэгчээс хамааралтай байдаг тул андуурдаг. Сервергүй технологийн хувьд ч мөн адил бөгөөд энэ нь буруу ойлголт биш юм. Бидний туршлагаас харахад AWS дээр сервергүй програмуудыг бүтээх нь AWS Lambda-н бусад AWS үйлчилгээг нэгтгэх чадвартай хослуулсан нь сервергүй архитектурын хүч чадлын нэг хэсэг юм. Энэ нь нэгдлийн үр дүн нь зөвхөн нэр томъёоны нийлбэрээс илүү гарах синергетикийн сайн жишээ юм. Борлуулагчийн хараат байдлаас зайлсхийхийг оролдох нь илүү олон асуудал үүсгэж болзошгүй юм. Контейнертэй ажиллахдаа үүлэн үйлчилгээ үзүүлэгчдийн хооронд өөрийн хийсвэр давхаргыг удирдах нь илүү хялбар байдаг. Гэхдээ сервергүй шийдлүүдийн тухайд, ялангуяа зардлын үр ашгийг эхнээс нь анхаарч үзвэл хүчин чармайлт үр дүнд хүрэхгүй. Борлуулагчид хэрхэн үйлчилгээ үзүүлж байгааг олж мэдэхээ мартуузай. Зарим төрөлжсөн үйлчилгээнүүд нь бусад үйлдвэрлэгчидтэй нэгтгэх цэг дээр тулгуурладаг бөгөөд хайрцагнаас гадуур залгаж, тоглуулах холболтоор хангадаг. Зарим контейнер эсвэл EC2 инстант руу хүсэлтийг прокси хийхээс илүү API-ийн эцсийн цэгээс Lambda дуудлагыг өгөх нь илүү хялбар байдаг. Graphcool нь Auth0-г хялбархан тохируулдаг бөгөөд энэ нь гуравдагч талын баталгаажуулалтын хэрэгслийг ашиглахаас илүү хялбар юм.
Сервергүй програмын зөв үйлдвэрлэгчийг сонгох нь архитектурын шийдвэр юм. Аппликейшн үүсгэх үед та хэзээ нэгэн цагт серверийн менежмент рүү буцаж ирнэ гэж бодохгүй байна. Клоуд борлуулагчийг сонгох нь контейнер эсвэл мэдээллийн сан, тэр ч байтугай програмчлалын хэлийг ашиглахаас ялгаатай биш юм.
Үүнд:
- Танд ямар үйлчилгээ хэрэгтэй вэ, яагаад.
- Үүлэн үйлчилгээ үзүүлэгчид ямар үйлчилгээ үзүүлдэг бөгөөд та тэдгээрийг сонгосон FaaS шийдэлтэйгээ хэрхэн хослуулах боломжтой.
- Ямар програмчлалын хэлийг дэмждэг (динамик эсвэл статик бичих, эмхэтгэх эсвэл тайлбарлах, жишиг үзүүлэлтүүд юу вэ, хүйтэн эхлүүлэхэд ямар гүйцэтгэлтэй байна, нээлттэй эхийн экосистем гэж юу вэ гэх мэт).
- Таны аюулгүй байдлын шаардлага юу вэ (SLA, 2FA, OAuth, HTTPS, SSL гэх мэт).
- CI/CD болон програм хангамж хөгжүүлэх мөчлөгөө хэрхэн удирдах вэ.
- Та ямар дэд бүтцийн шийдлүүдийн давуу талыг ашиглаж болох вэ?
Хэрэв та одоо байгаа програмаа өргөтгөж, сервергүй функцийг аажмаар нэмбэл энэ нь боломжит чадамжийг тодорхой хэмжээгээр хязгаарлаж болзошгүй. Гэсэн хэдий ч бараг бүх сервергүй технологиуд нь зарим төрлийн API (REST эсвэл мессежийн дарааллаар) өгдөг бөгөөд энэ нь програмын цөмөөс хамааралгүй, хялбар интеграцчилал бүхий өргөтгөлүүдийг үүсгэх боломжийг олгодог. Тодорхой API, сайн баримт бичиг, хүчирхэг нийгэмлэг бүхий үйлчилгээг хайж олоорой, та алдаа гаргаж чадахгүй. Интеграцчлахад хялбар байх нь гол хэмжигдэхүүн байж болох ба 2015 онд Lambda-г гаргаснаас хойш AWS яагаад ийм амжилттай байгаагийн гол шалтгаануудын нэг байж магадгүй юм.
Сервергүй байх үед
Сервергүй технологийг бараг хаа сайгүй хэрэглэж болно. Гэсэн хэдий ч тэдний давуу тал нь зөвхөн хэрэглээний нэг арга замаар хязгаарлагдахгүй. Сервергүй технологийн ачаар үүлэн тооцоололд нэвтрэхэд тулгарч буй саад бэрхшээл өнөөдөр маш бага байна. Хэрэв хөгжүүлэгчдэд санаа байгаа ч үүлэн дэд бүтцийг хэрхэн удирдах, зардлыг оновчтой болгох талаар мэдэхгүй байгаа бол үүнийг хэрэгжүүлэхийн тулд ямар нэгэн инженер хайх шаардлагагүй болно. Хэрэв стартап платформ бүтээхийг хүсч байгаа ч зардал нь хяналтаас гарах вий гэж эмээж байвал сервергүй шийдлүүд рүү амархан хандаж болно.
Зардал хэмнэж, өргөтгөхөд хялбар учраас сервергүй шийдлүүд нь олон сая үзэгчтэй вэб программ хүртэл дотоод болон гадаад системд адилхан хэрэглэгдэх боломжтой. Дансыг еврогоор биш харин центээр хэмждэг. AWS EC2 (t1.micro)-ийн хамгийн энгийн хувилбарыг нэг сарын турш түрээслэхэд та юу ч хийгээгүй ч гэсэн 15 еврогийн үнэтэй байх болно (хэн үүнийг унтраахаа мартаагүй юм бэ?!). Харьцуулбал, ижил хугацаанд зарцуулсан ийм түвшинд хүрэхийн тулд та 512 MB Lambda-г 1 секундын турш 3 сая орчим удаа ажиллуулах шаардлагатай болно. Хэрэв та энэ функцийг ашиглахгүй бол юу ч төлөхгүй.
Сервергүй нь үндсэндээ үйл явдалд тулгуурладаг тул хуучин системд сервергүй дэд бүтцийг нэмэх нь маш хялбар байдаг. Жишээлбэл, AWS S3, Lambda, Kinesis ашиглан та API-ээр дамжуулан өгөгдөл хүлээн авах боломжтой хуучин жижиглэн худалдааны системийн аналитик үйлчилгээг үүсгэж болно.
Ихэнх сервергүй платформууд олон хэлийг дэмждэг. Ихэнхдээ энэ нь Python, JavaScript, C#, Java болон Go юм. Ихэвчлэн бүх хэл дээрх номын санг ашиглахад ямар ч хязгаарлалт байдаггүй тул та дуртай нээлттэй эхийн номын санг ашиглах боломжтой. Гэсэн хэдий ч, таны функцууд оновчтой ажиллахын тулд хамаарлыг буруугаар ашиглахгүй байхыг зөвлөж байна, таны сервергүй програмуудын асар том өргөтгөх чадварын ашиг тусыг үгүйсгэхгүй. Илүү олон багцыг саванд хийх тусам хүйтэн эхлэхэд удаан хугацаа шаардагдана.
Хүйтэн эхлэл нь контейнер, ажиллах хугацаа, алдаа гаргагчийг ашиглахаасаа өмнө эхлээд эхлүүлэх хэрэгтэй. Үүнээс болж функцүүдийн гүйцэтгэлийн саатал 3 секунд хүртэл байж болох бөгөөд энэ нь тэвчээргүй хэрэглэгчдийн хувьд хамгийн сайн сонголт биш юм. Гэсэн хэдий ч, хэдэн минутын турш сул зогссоны дараа анхны дуудлагад хүйтэн эхэлдэг. Олон хүмүүс үүнийг сул зогсолттой байлгахын тулд функцийг тогтмол пинг хийснээр үүнийг арилгах боломжтой жижиг таагүй зүйл гэж үздэг. Эсвэл тэд энэ талыг бүхэлд нь үл тоомсорлодог.
Хэдийгээр AWS гаргасанГэсэн хэдий ч SQL өгөгдлийн сан нь гүйлгээ хийх холболтоос хамаардаг тул AWS Lambda дээр ачаалал ихтэй түгжрэл үүсгэдэг тул энэ програмын хувьд тийм ч тохиромжтой биш юм. Тиймээ, хөгжүүлэгчид Serverless Aurora-г байнга сайжруулж байдаг бөгөөд та үүнийг туршиж үзэх хэрэгтэй, гэхдээ өнөөдөр NoSQL шийдлүүд. Гэхдээ энэ байдал тун удахгүй өөрчлөгдөнө гэдэгт эргэлзэхгүй байна.
Хэрэгслийн хэрэгсэл нь ялангуяа орон нутгийн туршилтын чиглэлээр маш их хязгаарлалт тавьдаг. Хэдийгээр Docker-Lambda, DynamoDB Local болон LocalStack зэрэг шийдлүүд байдаг ч тэдгээр нь шаргуу хөдөлмөр, ихээхэн хэмжээний тохиргоо шаарддаг. Гэсэн хэдий ч эдгээр бүх төслүүд идэвхтэй хөгжиж байгаа тул хэрэглүүр нь бидний хэрэгцээтэй түвшинд хүрэх нь цаг хугацааны асуудал юм.
Сервергүй технологийн хөгжлийн мөчлөгт үзүүлэх нөлөө
Таны дэд бүтэц бол зүгээр л тохиргоо учраас та бүрхүүлийн скрипт гэх мэт скриптүүдийг ашиглан кодыг тодорхойлж, байрлуулж болно. Эсвэл та код болгон тохируулах ангиллын шийдлүүдийг ашиглаж болно . Хэдийгээр энэ үйлчилгээ нь бүх талбарт зориулсан тохиргоог өгдөггүй ч Lambda функц болгон ашиглах тусгай нөөцийг тодорхойлох боломжийг танд олгоно. Өөрөөр хэлбэл, CloudFormation танд амжилтгүй болсон тохиолдолд та энэ цоорхойг арилгах өөрийн нөөцийг (Lambda функц) бичиж болно. Ингэснээр та AWS орчноос гадуур хамаарлыг тохируулах хүртэл юу ч хийж болно.
Энэ бүхэн зүгээр л тохиргоо учраас та CloudFormation гэх мэт дэд бүтцийг код болгон ашиглаж байгаа бол тодорхой орчин, бүс нутаг, хэрэглэгчдэд зориулан байршуулах скриптүүдийг өөрчлөх боломжтой. Жишээлбэл, та репозитор дахь салбар тус бүрийн дэд бүтцийн хуулбарыг байрлуулж, хөгжүүлэлтийн явцад тэдгээрийг тусад нь бүрэн туршиж үзэх боломжтой. Энэ нь хөгжүүлэгчид өөрсдийн код нь амьд орчинд хангалттай ажиллаж байгаа эсэхийг ойлгохыг хүссэн тохиолдолд тэдний санал хүсэлтийг эрс хурдасгадаг. Менежерүүд зөвхөн бодит ашиглалтын төлбөрийг төлдөг тул олон орчныг ашиглах зардлын талаар санаа зовох шаардлагагүй болно.
DevOps нь зөвхөн хөгжүүлэгчид зөв тохиргоотой эсэхийг шалгах хэрэгтэй тул санаа зовох зүйл багатай. Та инстанц, тэнцвэржүүлэгч эсвэл аюулгүй байдлын бүлгүүдийг удирдах шаардлагагүй болсон. Тиймээс, дэд бүтцийг тохируулах, ялангуяа IAM тохиргоо болон үүлэн нөөцийг оновчтой болгоход чухал ач холбогдолтой хэвээр байгаа хэдий ч NoOps гэсэн нэр томъёо улам бүр хэрэглэгдэж байна.
Epsagon, Thundra, Dashbird, IOPipe зэрэг маш хүчирхэг хяналт, дүрслэх хэрэгслүүд байдаг. Эдгээр нь сервергүй программынхаа одоогийн байдлыг хянах, бүртгэл хөтлөх, хянах, гүйцэтгэлийн хэмжигдэхүүн, архитектурын хүндрэлийг арилгах, зардлын дүн шинжилгээ хийх, урьдчилан таамаглах гэх мэт олон боломжийг олгодог. Эдгээр нь DevOps-ын инженер, хөгжүүлэгчид, архитекторуудад програмын гүйцэтгэлийн талаархи цогц ойлголтыг өгөхөөс гадна менежерүүдэд секунд тутамд нөөцийн зардал, зардлын таамаглалыг ашиглан нөхцөл байдлыг бодит цаг хугацаанд хянах боломжийг олгодог. Удирдлагатай дэд бүтцээр үүнийг зохион байгуулах нь илүү хэцүү байдаг.
Сервергүй программуудыг зохион бүтээх нь илүү хялбар байдаг, учир нь та вэб сервер байрлуулах, виртуал машин эсвэл контейнер, засварын сервер, үйлдлийн систем, интернет гарц гэх мэтийг удирдах шаардлагагүй. Эдгээр бүх үүрэг хариуцлагыг хассанаар сервергүй архитектур нь үндсэн үндсэн дээр анхаарлаа төвлөрүүлж чадна - шийдэл.бизнес болон хэрэглэгчийн хэрэгцээ.
Хэрэгслийн хэрэгсэл нь илүү сайн байж болох ч (өдөр бүр сайжирч байгаа) хөгжүүлэгчид бизнесийн логикийг хэрэгжүүлэхэд анхаарлаа төвлөрүүлж, архитектурын янз бүрийн үйлчилгээнүүдэд програмын нарийн төвөгтэй байдлыг хамгийн сайн хуваарилах боломжтой. Сервергүй програмын удирдлага нь үйл явдалд суурилсан бөгөөд үүлэн үйлчилгээ үзүүлэгчийн хийсвэрлэл юм (жишээ нь, SQS, S3 үйл явдлууд эсвэл DynamoDB урсгалууд). Тиймээс хөгжүүлэгчид зөвхөн тодорхой үйл явдалд хариу өгөхийн тулд бизнесийн логик бичих хэрэгтэй бөгөөд мэдээллийн сан, мессежийн дарааллыг хэрхэн хамгийн сайн хэрэгжүүлэх, эсвэл тодорхой техник хангамжийн агуулах дахь өгөгдөлтэй оновчтой ажлыг хэрхэн зохион байгуулах талаар санаа зовох хэрэггүй болно.
Аливаа хөгжүүлэлтийн процессын нэгэн адил кодыг дотооддоо ажиллуулж, дибаг хийх боломжтой. Нэгжийн туршилт ижил хэвээр байна. Тусгай стекийн тохиргоо бүхий програмын дэд бүтцийг бүхэлд нь байрлуулах чадвар нь хөгжүүлэгчдэд туршилтын зардал эсвэл үнэтэй удирддаг орчинд үзүүлэх нөлөөллийн талаар бодохгүйгээр чухал санал хүсэлтийг хурдан авах боломжийг олгодог.
Сервергүй програмуудыг бүтээх хэрэгсэл, арга техник
Сервергүй програмуудыг бүтээх тусгай арга байхгүй. Мөн энэ ажилд зориулсан үйлчилгээний багц. AWS нь өнөөдөр хүчирхэг сервергүй шийдлүүдийн дунд тэргүүлэгч боловч бас хараарай , и . Хэрэв та AWS ашиглаж байгаа бол програм цуглуулахад санал болгож буй арга (SAM), ялангуяа C# ашиглах үед, учир нь Visual Studio маш сайн хэрэгсэлтэй. SAM CLI нь Visual Studio-ийн хийж чадах бүх зүйлийг хийх боломжтой тул та өөр IDE эсвэл текст засварлагч руу шилжвэл юу ч алдахгүй. Мэдээжийн хэрэг, SAM нь бусад хэлтэй ажилладаг.
Хэрэв та бусад хэлээр бичиж байгаа бол Сервергүй Framework нь маш хүчирхэг YAML тохиргооны файлуудыг ашиглан аливаа зүйлийг тохируулах боломжийг олгодог маш сайн нээлттэй эхийн хэрэгсэл юм. Сервергүй хүрээ нь янз бүрийн үүлэн үйлчилгээг дэмждэг тул бид үүнийг олон үүлний шийдлийг хайж буй хүмүүст зөвлөж байна. Энэ нь ямар ч хэрэгцээнд зориулж олон тооны залгаасуудыг бий болгосон асар том нийгэмлэгтэй.
Орон нутгийн тест хийхэд Docker-Lambda, Serverless Local, DynamoDB Local, LocalStack зэрэг нээлттэй эхийн хэрэгслүүд тохиромжтой. Сервергүй технологиуд нь хөгжүүлэлтийн эхний шатандаа байгаа тул тэдгээрт зориулсан хэрэгслүүд нь нарийн төвөгтэй туршилтын хувилбаруудыг тохируулахдаа та шаргуу ажиллах хэрэгтэй болно. Гэсэн хэдий ч стекийг зүгээр л орчинд байрлуулж, тэнд туршиж үзэх нь үнэхээр хямд юм. Мөн та үүлэн орчныг яг таг хуулбарлах шаардлагагүй.
AWS Lambda Layers ашиглан суулгасан багцуудын хэмжээг багасгаж, татаж авах ажиллагааг хурдасгана.
Тодорхой ажлуудад тохирох програмчлалын хэлийг ашигла. Өөр өөр хэлүүд өөрийн гэсэн давуу болон сул талуудтай байдаг. Олон шалгуур үзүүлэлтүүд байдаг ч JavaScript, Python болон C# (.NET Core 2.1+) нь AWS Lambda гүйцэтгэлийн хувьд тэргүүлдэг. AWS Lambda саяхан Runtime API-г танилцуулсан бөгөөд энэ нь танд хүссэн ажиллах цагийн хэл болон орчныг зааж өгөх боломжийг олгодог тул туршаад үзээрэй.
Байршуулахын тулд багцын хэмжээг жижиг байлгах хэрэгтэй. Тэд бага байх тусам хурдан ачаалагддаг. Том номын санг ашиглахаас зайлсхий, ялангуяа тэдгээрийн хэд хэдэн функцийг ашигладаг бол. Хэрэв та JavaScript дээр программчилж байгаа бол бүтээцээ оновчтой болгохын тулд Webpack гэх мэт бүтээх хэрэгслийг ашигла, зөвхөн танд хэрэгтэй зүйлээ оруулна уу. .NET Core 3.0 нь QuickJit болон шаталсан эмхэтгэлтэй бөгөөд энэ нь гүйцэтгэлийг сайжруулж, хүйтэн үед маш их тусалдаг.
Үйл явдалд сервергүй функцууд найдах нь эхлээд бизнесийн логикийг зохицуулахад хэцүү болгодог. Үүнтэй холбогдуулан мессежийн дараалал болон төрийн машинууд нь үнэхээр хэрэгтэй байж болох юм. Lambda функцууд бие биенээ дуудаж болно, гэхдээ та хариу хүлээхгүй байгаа тохиолдолд л үүнийг хийнэ үү ("гал ба март") - өөр функц дуусахыг хүлээхийн тулд төлбөр авахыг хүсэхгүй байна. Мессежийн дараалал нь бизнесийн логикийн зарим хэсгийг тусгаарлах, програмын саад тотгорыг удирдах, гүйлгээг боловсруулахад хэрэгтэй (FIFO дарааллыг ашиглан). AWS Lambda функцуудыг SQS дараалалд гацсан мессежийн дараалал болгон хуваарилж, дараа нь дүн шинжилгээ хийх зорилгоор амжилтгүй болсон мессежийг бүртгэж болно. AWS Step Functions (төрийн машинууд) нь функцуудыг гинжлэх шаардлагатай нарийн төвөгтэй процессуудыг удирдахад маш хэрэгтэй байдаг. Өөр функцийг дууддаг Lambda функцийн оронд алхам функцууд нь төлөвийн шилжилтийг зохицуулах, функцуудын хооронд өгөгдөл дамжуулах, функцүүдийн глобал төлөвийг удирдах боломжтой. Энэ нь дахин оролдох нөхцөлийг тодорхойлох, эсвэл тодорхой алдаа гарсан үед юу хийх талаар тодорхойлох боломжийг олгодог - тодорхой нөхцөлд маш хүчирхэг хэрэгсэл юм.
дүгнэлт
Сүүлийн жилүүдэд сервергүй технологиуд урьд өмнө байгаагүй хурдацтай хөгжиж байна. Энэхүү парадигмын өөрчлөлттэй холбоотой зарим буруу ойлголтууд байдаг. Дэд бүтцийг хийсвэрлэж, менежментийг өргөжүүлснээр сервергүй шийдлүүд нь хялбаршуулсан хөгжүүлэлт, DevOps процессуудаас эхлээд үйл ажиллагааны зардлыг их хэмжээгээр бууруулах хүртэл ихээхэн ашиг тусыг өгдөг.
Сервергүй арга нь сул талгүй ч гэсэн хүчирхэг сервергүй програмуудыг бүтээх эсвэл сервергүй элементүүдийг одоо байгаа архитектурт нэгтгэхэд ашиглаж болох бат бөх дизайны загварууд байдаг.
Эх сурвалж: www.habr.com